QuickBooks ile Amazon Satışlarını Otomatik Senkronize Etmek: Pratik Rehber

Her ay sonu aynı sahne: muhasebeci elinde Amazon Settlement Report, masada açık QuickBooks Online, yanında kahve. 3 gün boyunca hangi kalemin nereye gittiğini bulma savaşı. Bir order satıştır ama içinde 4 farklı kalem vardır: ürün geliri, FBA ücreti, referral fee, sales tax. Refund geldiğinde bu 4 kalem negatife döner ama tarihler farklı, dolayısıyla “şu ay net” hesabı kayar.

Bu yazıda manuel mutabakatın neden sürdürülemez olduğunu, otomatik senkronizasyonun 4 mimari kuralını ve canlıya alma sırasında karşılaştığımız en sık 3 tuzağı paylaşıyoruz.

Manuel mutabakatın gerçek maliyeti

Ortalama bir Amazon US satıcısı (aylık 800–1.500 sipariş, $40K–$120K hacim) için manuel mutabakatın maliyeti şöyle:

Kalem	Aylık süre	Yıllık maliyet (TL)
Settlement report indirme + parsing	2 saat	6.000
Refund/return eşleştirme	3 saat	9.000
FBA fee + storage fee allocation	2 saat	6.000
Sales tax kalemi (eyalet bazlı)	2 saat	6.000
Mutabakat sapmalarını bulma	3 saat	9.000
Toplam	12 saat / ay	~36.000 TL / yıl

12 saatlik manuel iş aynı zamanda insan hatasına açık — yanlış eşleştirilen bir refund, vergi beyannamesinde ay sonu sapma demektir. Bunu aylar sonra fark ederseniz CFO’nun masasında 6–12 aylık geriye dönük düzeltme durur.

Otomasyon bu 12 saati ayda 30 dakikaya indirir (sadece anomali kontrolü). Ama her otomatik araç işi düzgün yapmaz — mimari kuralları ihmal eden çözümler aynı sapmayı gizler, çözmez.

4 mimari kural

1. Order ≠ tek bir GL kalemi

QuickBooks’a Amazon order’ı tek bir Sales olarak yazmak en sık yapılan hata. Doğrusu order’ı 4 ayrı line item’a parçalamaktır:

Product Sales (gross revenue, ürün satış geliri)
FBA Fees (Amazon’ın aldığı kesinti — gider)
Referral Fee (kategori bazlı %8-15 kesinti — gider)
Sales Tax Collected (Amazon facilitator yasası gereği topladığı vergi — liability)

Bu yapıyı kurmazsanız, gross revenue rakamınız Amazon dashboard’undakiyle uyuşmaz. Vergi beyannamesinde başınız ağrır.

2. Payout ≠ Sales — payout bir transfer’dir

Amazon her 14 günde bir Mercury (veya hangi bankayı kullanıyorsanız) hesabınıza payout yapar. Bu satış değildir — sadece daha önce kaydedilmiş satışlardan ürettiğiniz alacağın bankaya geçişidir.

Doğru kayıt:

Bank Account (Mercury)        +$8.450
Accounts Receivable (Amazon)         -$8.450

Yanlış kayıt (yaygın hata):

Bank Account (Mercury)        +$8.450
Sales Revenue                          +$8.450  ← çift sayım!

Bu yanlışı yaparsanız geliriniz 2 kat görünür. Vergi mükellefi olarak fazla gelir beyan etmek istemezsiniz.

3. Refund’lar negatif satış değil, ayrı bir GL kalemidir

Bir müşteri ürünü iade ettiğinde Amazon size 4 negatif kalem yansıtır:

Negative product revenue (iade tutarı)
Negative referral fee (geri verilen komisyon)
Negative FBA fee (geri verilen fulfillment ücreti — bazen)
Negative sales tax (geri verilen vergi)

QuickBooks’ta bunları Refund Receipt olarak kaydedin, Sales Receipt’i negatife çekme. Refund Receipt ayrı bir transaction tipi — finansal raporlarda gerçek “iade oranı” görünmesi için bu zorunlu.

4. Reserve hesabını liability olarak takip edin

Amazon yeni satıcılar için %20-30 oranında “reserve” tutar — bu para hesabınızda görünmez ama size aittir. QuickBooks’ta bu bir Other Current Asset veya Restricted Cash hesabıdır. Eğer reserve’i hesaba katmazsanız:

Cash flow projeksiyonunuz eksik olur
Reserve serbest kaldığında payout şişer ve “bu nereden geldi” diye saatler harcarsınız

Manuel ve otomatik mutabakatın kıyası

	Manuel	Otomatik (sapmasız)
Aylık süre	12 saat	30 dk (anomali kontrolü)
İnsan hatası riski	Yüksek	Düşük (idempotent retry)
Geriye dönük sorgulama	”Hangi excel’deydi?”	Tek tıkla event geçmişi
Vergi beyannamesi hızı	3-5 iş günü hazırlık	Aynı gün export
Sapma tespit süresi	Ay sonu	Anlık (webhook + alert)

Uygulamada en sık 3 tuzak

Tuzak 1: Sandbox’ta çalışan kod, production’da timeout

QuickBooks Online API’si rate-limit’lidir — saniyede 10 istek, dakikada 500. Sandbox’ta 50 order’lık test çalışır, production’da 5.000 order’lık bir günü aktarmaya çalışırken timeout alırsınız. Çözüm:

Idempotency-Key her batch’te kullanın (duplicate önler)
Backoff retry (exponential, jitter’lı)
Cursor-based sync (son sync timestamp’inden devam)
Worker queue (BullMQ veya benzeri)

Tuzak 2: Time zone uyuşmazlığı

Amazon Settlement raporları PT (Pacific Time), QuickBooks tenant’ı EST veya TR. Bir ay sonu işlemi PT’da 31 Mart, EST’de 1 Nisan görünür. Bu sapma vergi dönemi geçişlerinde felakettir. Çözüm: TÜM order date’lerini UTC’ye normalize edin, QuickBooks tarafında tenant timezone’una çevirin.

Tuzak 3: “Auto-categorization” güvenmeyin

QuickBooks’un kendi auto-rule’ları “Amazon Marketplace” olarak gelen tüm transactions’ı otomatik kategorize eder. Ama bu rule payout’u Sales sanır. Mutlaka manuel mapping yapın veya bir middleware (tsmartb2b gibi) kullanın.

tsmartb2b’de bunu nasıl çözdük

tsmartb2b bu 4 kuralı varsayılan olarak uygular. Müşterimiz:

QuickBooks Online’ı OAuth ile bağlar (5 dk)
Amazon Seller Central’ı OAuth ile bağlar (5 dk)
tsmartb2b mapping wizard’ında 4 GL kalemini onaylar (default’lar %95 doğru)
İlk sync aynı gün başlar — son 90 günü geriye sync eder

Sonrası: her order, refund, fee, payout otomatik. Webhook ile real-time. Dashboard’da kullanım grafiği, plan üstü uyarısı, DLQ replay tek tıkla.

Starter $49/ay planı 1 QB + 2 connector + aylık 10.000 sync event ile başlar. 14 gün ücretsiz, kart vermeden.

Kararı kendiniz verin

Eğer aylık 200’den az order’ınız varsa manuel mutabakat hâlâ sürdürülebilir. 500+ order ve çok kanal (Amazon + Shopify + Walmart) varsa otomasyon kaçınılmaz. Otomasyon seçerken yukarıdaki 4 mimari kuralı sorgulayın — uymayan araçlar kısa vadede çalışır, uzun vadede sapmayı gizler.

Sapma gizlemek, çözmekten pahalıdır — fark sadece zamanlamadadır.

İlgili rehber: Stripe + QuickBooks entegrasyonu için pratik kılavuz — ABD LLC + Stripe Atlas kuran TR markaları için.