Stripe Connect Marketplace Accounting Workflow

A practitioner's guide to posting charges, fees, transfers, refunds, disputes, and reserves into a marketplace ledger that reconciles cleanly.

Çoğu pazar yeri muhasebesi sorununun kökeni tek bir hataya dayanır: Stripe banka ödemesini (payout) sanki gelirmiş gibi ele almak. Ödeme; onlarca ayrı ekonomik olayın net bakiyesidir ve bunu tek bir gelir kalemi olarak deftere kaydetmek, platformun komisyonunu, satıcının borcunu ve içinde gömülü olan tüm masraf ve itirazları ortadan kaldırır. Doğru bir iş akışı, hiçbir şey deftere işlenmeden önce ödemeyi alt bileşenlerine ayırır.

Bu rehber, her bir Stripe Connect bakiye işlem kategorisini (balance transaction) doğru muhasebe hesaplarına yerleştirir: alacaklar, komisyon gelirleri, satıcı borçları, işlem masrafları ve mutabakat bekletme hesapları. İşleme mekanizması olarak Nordlet'in belgelenmiş içe aktarım ve mutabakat uç noktalarını (endpoint) kullanır, çalışılmış bir ödeme mutabakatı örneği sunar ve her kapanıştan önce çalıştırabileceğiniz bir mutabakat kontrol listesiyle sona erer.

Herhangi bir şey tasarlamadan önce Connect ödeme modelini belirleyin

Her ödeme akışının hangi ücretlendirme modelini kullandığını bilmeden muhasebe kuralları yazılamaz. Model, masrafın hangi Stripe bakiyesine yansıyacağını, ücretleri kimin üstleneceğini ve iade ile itirazların ilk olarak nereye çarpacağını belirler.

Connect modeli	Üzerinde oluşturulan işlem	Stripe ücretlerini üstlenen	İadeler/itirazlar azaltır	Muhasebe sonucu
Doğrudan ödemeler (Direct charges)	Bağlı hesap (Connected account)	Taraflara göre yapılandırılabilir	Bağlı hesabın bakiyesi	Platform, aldığı hizmet bedelini gelir olarak kaydeder; satıcı ödeme faaliyetleri çoğunlukla bağlı hesap defterinde yaşar
Hedef ödemeler (Destination charges)	Platform, bir bağlı hesaba anında transfer ile	Platform	Platform	Platform, müşteri alacağını ve Stripe ücretini kaydeder; satıcı payı gelir değil, ödenecek borçtur
Ayrı ödemeler ve transferler (Separate charges and transfers)	Platform ödemesi, ardından bir veya daha fazla ayrı transfer	Platform	Platform	Ödeme ve satıcı transferleri ayrı olaylardır; satıcı borcu müşteri ödemesinden bağımsız olarak izlenir

Stripe'ın Connect entegrasyonunda ödemelerin nasıl çalıştığına dair kendi kılavuzu, hedef ödemeler ile ayrı ödemeler ve transferler için platform bakiyesinin ödeme ücretlerini, iadeleri ve ters ibrazları (chargeback) üstlendiğini doğrular. Doğrudan ödemelerde ise bağlı hesap ödemeyi alır ve ücretler her iki taraftan da borç kaydedilebilir.

Pratik kural şudur: Her bir akış için ücretlendirme modelini kaleme almadan "Stripe ödemesi satıcı geliridir" veya "ücretleri satıcı öder" demeyin. Bu modeli her işlemle birlikte saklayın. Doğrudan ve hedef ödemeleri tek bir muhasebeleştirme kuralı altında karıştırmak; hem geliri hem de borcu yanlış beyan etmenin en kısa yoludur.

Bu rehber, platform bakiyesinin muhasebe yükünü taşıdığı ve çoğu pazar yeri defterinin kurulduğu yer olduğu için hedef ödemeleri veya ayrı ödemeler ile transferleri varsayar.

Tek bir satırı içe aktarmadan önce fon akışını haritalandırın

İçe aktarma işlemine başlamadan önce her akış için tek sayfalık bir işlem haritası çizin:

Müşteri ödemesi
  -> Stripe ödemesi / ödeme bakiye işlemi
  -> Stripe ücreti
  -> platform hizmet bedeli (komisyon)
  -> bağlı hesaba transfer
  -> iade veya itiraz (varsa)
  -> Stripe ödemesi (payout)
  -> banka tahsilatı

Her ok; kendi kimliğine (ID), kategorisine, tutarına ve tarihlerine sahip, ayrı bir bakiye işlemidir. Stripe bakiyesini banka benzeri bir takas hesabı (clearing account) olarak ele alın: ödemeler içeri akar, ücretler ve transferler dışarı akar ve ödeme (payout) kalanı gerçek bankaya taşır. Nordlet'in banka ve ödeme içe aktarma belgeleri, normal Stripe faaliyetleri için tam olarak bu muameleyi önermektedir.

Doğru Stripe kaynak raporunu seçin

Otomatik ödeme (automatic payout) mutabakat serileri için Stripe'ın Ödeme mutabakatı, kalem kalem (Payout reconciliation, itemized) raporunu kullanın. Bu rapor, bakiye işlemi başına bir satır verir, satırları reporting_category alanına göre gruplandırır, her birini bir automatic_payout_id ile ilişkilendirir ve brüt, ücret ile net toplamları sağlar. Stripe'ın rapor seçim kılavuzu bu raporu belgelemekte ve charge_id, connected_account_id ile destination_payment_id alanlarını mevcut Connect alanları olarak doğrulamaktadır.

Otomatik ödemelerin etkinleştirilmediği durumlarda (bazı manuel ödeme düzenlemeleri), bunun yerine Bakiye (Balance) raporunu kullanın. Panel (Dashboard) ödeme özetini deftere kayıt için yeterli kanıt olarak görmeyin. Özet yalnızca parti toplamını kanıtlar; bileşenleri yalnızca kalem kalem dökümü verilen rapor açıklar.

Stripe, eski type alanı yerine reporting_category değerine göre sınıflandırma yapılmasını önerir ve her satır, alttaki nesneye bağlanan bir source kimliği taşır. Zamanlama kısıtlamasına dikkat edin: Stripe, günlük rapor verilerinin normalde ertesi gün öğleye kadar hazır olduğunu belirtir ve anlık ödemelerin (instant payouts) bireysel işlemlere temiz bir şekilde atanamayacağını, bu nedenle ayrı bir işlem geçmişi mutabakatına ihtiyaç duyduklarını ifade eder.

Her bakiye işlemini kategorisine göre sınıflandırın

Birincil sınıflandırıcı olarak reporting_category alanını kullanın, ardından source_id, charge_id ve açıklamaları inceleyin. Önem taşıyan eşleştirme tablosu şöyledir:

Stripe faaliyeti	Raporlama kategorisi (`reporting_category`)	Muhasebe yorumu
Müşteri ödemesi, kart veya yerel ödeme yöntemi	`charge`	Müşteri finansmanlı alacak veya satış mutabakatı
İade	`refund`	Orijinal müşteri ödemesinin iptali
Stripe tarafından alıkonulan işlem ücreti	`fee`	Ödeme işlem gideri
Platform hizmet bedeli	`platform_earning`	Komisyon geliri
İade edilen hizmet bedeli	`platform_earning_refund`	Komisyon gelirinin azalması
Bağlı hesaba transfer	`transfer`	Satıcı borcunun azalması
İptal edilen transfer	`transfer_reversal`	Bağlı hesaptan tahsilat
Ters ibraz (Chargeback)	`dispute`	Ters ibraz zararı; kaynak itiraz nesnesini inceleyin
Kazanılan veya iptal edilen ters ibraz	`dispute_reversal`	Önceden kaydedilmiş bir ters ibrazın tahsilatı
Bankaya ödeme (Payout)	`payout`	Banka hareketi, gelir değil
İptal edilen ödeme	`payout_reversal`	Fonların Stripe bakiyesine iadesi
Tutulan rezerv	`connect_reserved_funds` / `risk_reserved_funds`	Kısıtlı fonlar, varsayılan olarak gider değil
Uzun süredir devam eden eksi bakiye tahsilatı	`connect_collection_transfer`	Risk politikası gerektiren fonlama veya tahsilat olayı

Terminolojiye dair bir uyarı: Eski bakiye işlemi type alanı, payment, application_fee ve adjustment dahil olmak üzere aynı olaylar için farklı etiketler kullanır. Stripe'ın bakiye işlem türleri belgeleri her iki kelime dağarcığını da listeler. Bir type değerini bir reporting_category kuralıyla karıştırmayın ve Stripe'ın dışa aktarmadığı dispute_loss gibi bir kategori uydurmayın. Dışa aktarılan veride tanımadığınız bir etiket varsa, dışa aktarılan değeri koruyun ve kaynak nesneye karşı doğrulayın.

Normal pazar yeri faaliyetini deftere kaydedin

Hedef ödemeler veya ayrı ödemeler ve transferler kullanan bir platform için kavramsal yevmiye kayıtları şunlardır:

Müşteri ödemesi (müşteri parası Stripe takas bakiyesine girer):

Borç  Stripe takas hesabı     Brüt müşteri ödemesi
    Alacak  Ticari alacaklar     Brüt müşteri ödemesi

Stripe işlem ücreti:

Borç  Stripe komisyon gideri   Stripe ücreti
    Alacak  Stripe takas hesabı    Stripe ücreti

Muhasebe politikanız net sunumu açıkça gerektirmediği ve desteklemediği sürece, Stripe ücretini gelirden mahsup ederek netleştirmeyin.

Platform komisyonu (aksi takdirde satıcıya borçlanılacak tutardan ayrılan sizin geliriniz):

Borç  Satıcıya borçlar         Komisyon tutarı
    Alacak  Komisyon geliri      Komisyon tutarı

Satıcı transferi (borcun ödenmesi, bir gider kalemi değil):

Borç  Satıcıya borçlar         Transfer tutarı
    Alacak  Stripe takas hesabı    Transfer tutarı

Bir transfer hiçbir zaman otomatik olarak bir gider değildir. Satıcının payı, ödeme düştüğü anda bir borç haline gelir ve transfer bu borcu kapatır. Nordlet'in mutabakat kayıt kuralları bunu takip eder: platform_earning satırları komisyon gelirine kaydedilirken, transfer satırları satıcı borcunu azaltır. Belgelenen varsayılan kayıt anahtarları şunlardır: Nordlet API içindeki kayıt kuralları aracılığıyla her biri şirket bazında geçersiz kılınabilecek şekilde settlements.commissionRevenue (varsayılan 5001), settlements.sellerPayable (varsayılan 4499), settlements.fees (varsayılan 6800) ve settlements.suspense (varsayılan 4440).

İadeleri gevşek banka kalemleri olarak değil, orijinal satışa istinaden ele alın

Bir iade, orijinal ödemeye veya faturaya bağlanır. Kavramsal olarak:

Borç  İadeler / satış iptalleri    İade tutarı
    Alacak  Ticari alacaklar           İade tutarı

Gerçek yevmiye kaydı; satışın tahakkuk edip etmediğine, verginin tersine çevrilip çevrilmeyeceğine ve platform hizmet bedelinin iade edilip edilmediğine bağlıdır. Tek bir iade; alacak ters kaydı, vergi ters kaydı, hizmet bedeli iadesi, transfer ters kaydı veya satıcı borcunda azalma ve varsayılmak yerine kontrol edilmesi gereken bir Stripe ücreti sonucu doğurabilir.

Zamanlama tuzağı: İade genellikle orijinal ödemeden daha sonraki bir ödeme serisinde (payout) sonuçlanır. Ödeme seviyesindeki bir dışa aktarımdan türetilmiş bir iade yerine, kalem kalem ödeme mutabakatı raporunu tercih edin. Nordlet belgeleri, Payments dışa aktarımından türetilen bir iadenin, iade daha sonra sonuçlandığında yalnızca bir tahmin olduğunu açıkça uyarmaktadır. Mutabakat içe aktarıcısı, iade satırını alabilir, orijinal satışla eşleştirebilir ve seri deftere işlendiğinde alacağı tersine çevirebilir.

İtirazları (disputes) iadelerden ayrı tutun

İtiraz, kart sahibinin veya ihraç eden bankanın talebidir ve Stripe, çözümden önce hem itiraz edilen tutarı hem de bir itiraz ücretini hesaptan düşebilir. Hedef ödemeler ile ayrı ödemeler ve transferler için Stripe, iade ve itiraz kılavuzuna göre her ikisini de platform bakiyesinden düşer. Platform, satıcı transferini tersine çevirerek tahsilat denemesi yapabilir.

Platform açısından kaybedilen bir itiraz:

Borç  Ters ibraz zararı / yeniden açılan alacak  İtiraz edilen tutar
Borç  Ters ibraz ücreti gideri                    İtiraz ücreti
    Alacak  Stripe takas hesabı                   Toplam tutar

Zararı satıcı üstleniyorsa ve tahsilat onaylandıysa:

Borç  Satıcıya borçlar / tahsilat hesabı         Tahsil edilebilir tutar
    Alacak  Ters ibraz tahsilatı                Tahsil edilebilir tutar

Yalnızca bir transfer ters çevirme talebinde bulunulduğu için satıcı tahsilatı kaydetmeyin. Ters çevirme işleminin oluşturulduğunu, başarılı olduğunu ve Stripe bakiyesinde göründüğünü doğrulayın. İtiraz kazanılırsa, Stripe itiraz edilen tutarı bir dispute_reversal satırı aracılığıyla iade eder; ters ibraz zararını iptal edin ve Stripe'ın iade etmediği herhangi bir itiraz ücretini ayrı olarak ele alın. Nordlet, aynı dosyadaki veya daha önceki bir içe aktarımdan daha önce eşleştirilmiş bir ödemenin charge_id değerini kullanarak ters ibraz satırlarını eşleştirir.

Çalışılmış bir mutabakat örneği

Tek bir otomatik ödeme serisini (payout batch) ele alalım. Kalem kalem raporda şunlar yer almaktadır:

Bir charge satırı: brüt 100,00, Stripe ücreti 3,20, net 96,80
Bir platform_earning satırı: 15,00, platformun komisyonu
Bağlı satıcıya yönelik bir transfer satırı: 81,80
Daha önceki bir satıştan bir refund satırı: brüt 20,00, bu seride sonuçlanıyor
Bir payout satırı: bankaya taşınan seri toplamı

Stripe'ın mutabakat kimliğine (settlement identity) göre ödeme kompozisyonu:

Brüt ödemeler               100,00
- iadeler                    20,00
- Stripe ücretleri            3,20
- transferler                81,80
= platform bakiyesine net    -5,00

platform_earning satırı parayı ikinci kez hareket ettirmez. Ücret ve satıcı transferi çıktıktan sonra platform bakiyesinde kalan 15,00 tutarı belirtir, böylece platform bunu varsaymak yerine komisyon geliri olarak tahakkuk ettirebilir.

Burada satıcı transferi artı iade, net ödeme faaliyetini aşmaktadır, bu nedenle seri küçük bir eksi bakiye ile kapanır ve sonraki ödemeyi azaltır veya bakiyeden çeker. Kaydedilen yevmiye kaydı, iade edilen alacağı tersine çevirir, 15,00 komisyon geliri kaydeder, 3,20 ücret gideri kaydeder, transfer yoluyla satıcı borcunu azaltır ve iade ters kaydını gerçekleştirir. Banka satırı, hesaba ulaşan net tutarla eşleşir. Hiçbir tekil rakam "gelir" anlamına gelmez, mesele de budur.

Nordlet'in mutabakat uç noktası (endpoint) aracılığıyla içe aktarın ve deftere kaydedin

Ödeme düzeyinde mutabakat için şunu kullanın:

POST /v1/bank/settlements/import

Stripe sağlayıcısı ve kalem kalem CSV dosyası ile. Nordlet, satırları automatic_payout_id değerine göre gruplandırır, her ödemeyi brüt, ücret ve net toplamlarla bir mutabakat serisine dönüştürür, halihazırda kaydedilmiş bir ödemenin yeniden içe aktarımlarını atlar, ödeme kompozisyonundan payout satırlarını atlar ve sipariş, fatura, PaymentIntent, charge, source veya metadata referanslarını kullanarak charge, refund ve dispute satırlarını otomatik olarak eşleştirir. Stripe, kalem kalem raporu bölüm başına bir dosyaya böler, bu nedenle charge, refund ve fee dosyalarını birlikte içe aktarın: halihazırda içe aktarılmış ancak henüz deftere işlenmemiş bir ödemeye ait satırlar mevcut seride birleştirilir. Bu, canlı bir Stripe bağlayıcısı değil; dosyalar ve mutabakat uç noktaları tarafından yönlendirilen bir içe aktar ve deftere kaydet iş akışıdır; özellikler sayfası, banka ve mutabakat tarafının neleri kapsadığını listeler.

Şu sırayla eşleştirin: ödemeleri faturalara, iadeleri orijinal ödemelere, itirazları orijinal ödemelere, komisyon satırlarını komisyon muamelesine. Stripe ücretlerini, düzeltmeleri, rezervleri ve ödeme satırlarını fatura eşleştirmesinin dışında tutun. Nordlet'in ödeme mutabakatı sözlüğü, ücret ve düzeltme hatlarının tasarımları gereği faturalarla eşleştirilemediğini belirtir; çözümlenmemiş para taşıyan kalemleri bekletme (suspense) hesabına yönlendirin. Manuel düzeltme, eşleştirmeyi kaldırmak için null bir invoiceId ile birlikte bank/settlements/match { lineId, invoiceId } kullanır.

Ardından dengeli bir seriyi deftere kaydedin:

POST /v1/bank/settlements/post

Bu, dengeli tek bir yevmiye oluşturur, eşleşen faturaları kapatır, net ödeme için banka hesabının defter hesabına borç kaydeder, ücretleri borç kaydeder, ödemeler için alacakları alacak kaydeder, iadeler ve ters ibrazlar için alacakları tersine çevirir, commissionPercent sağlandığında eşleşmeyen pazar yeri ödemelerini komisyon geliri ile satıcı borcu arasında böler ve çözümlenmemiş tutarları bekletme hesabına gönderir. Tanımadığı herhangi bir kategori de bekletme hesabına düşer ve yanıt, bunları sessizce içine sindirmek yerine bir uyarı içinde bu kategorileri adlandırır.

Mutabakat kontrol listesi

Her kapanıştan önce şu doğrulamaları çalıştırın:

Yinelenen balance_transaction_id yok
Yinelenen (provider, payout_id) mutabakat serisi yok
Satır net toplamları seri netine eşit
Seri neti, zamanlama ve para birimi politikasına tabi olarak banka ödemesine eşit
Her iadenin orijinal bir ödemesi veya kaydedilmiş bir istisnası var
Her itirazın bir itiraz veya ödeme referansı var
Her transferin bir bağlı hesap kimliği (connected-account ID) var
Her platform_earning satırının tanımlanmış bir komisyon muamelesi var
Bekletme hesabı sıfır veya tamamen gözden geçirilmiş durumda (kayıt uyarısında adı geçen tanınmayan kategoriler dahil)
Satıcı borcu, onaylanmış bir avans veya tahsilat politikası olmaksızın eksi (negatif) değil
Kaydedilmiş seriler sessizce yeniden içe aktarılamaz veya yeniden deftere işlenemez
Şirketin baz para biriminden farklı bir para birimindeki ödeme, ödeme tarihi kuruyla çevrilir; her faturanın kendi kuruyla olan farkı gerçekleşen kur farkı geliri veya gideri olarak kaydedilir; para birimlerini karıştıran bir ödeme, içe aktarım sırasında reddedilir

Üç düzeyde mutabakat yapın: satır (her işlemin korunan bir kimliği, kategorisi, tutarı, para birimi, kaynağı vardır), ödeme (kalem kalem netler, Stripe ödemesine ve banka tahsilatına eşittir) ve defter (kaydedilen yevmiye dengededir ve amaçlanan gelir, ücret, alacak, satıcı borcu ve bekletme pozisyonlarını üretir). Özellikle satıcı bakiye hesapları için, açılış satıcı borcu artı yeni satıcı payı, eksi transferler ve geçerli ters kayıtların, kapanış satıcı borcuna eşit olduğunu doğrulayın.

Her pazar yeri defterindeki yinelenen hata, başladığı hatayla aynıdır: yapılandırılmış bir ödemeyi (payout) tek bir rakama indirgemek. Bileşenleri ayrı tutun, her birini kararlı bir Stripe tanımlayıcısına bağlayın ve henüz açıklayamadığınız her şeyi bekletme hesabında tutun. Temiz bir kapanış, bir denetçinin güveneceği şeydir.

SSS

Stripe ödemesi platformun geliri midir?

Hayır. Ödeme; aynı seride sonuçlanmayı başaran ödemelerin, iadelerin, işlem ücretlerinin, satıcı transferlerinin, itirazların ve düzeltmelerin netidir. Bunu tek bir gelir kalemi olarak kaydetmek, içindeki satıcı borcunu ve işlem masrafını ortadan kaldırır. Bir aracı pazar yeri için gelir, platform_earning satırlarının tanımladığı komisyondur.

Hangi Stripe raporuna karşı mutabakat yapmalıyım?

Ödeme mutabakatı, kalem kalem (Payout reconciliation, itemized) raporu; çünkü reporting_category, automatic_payout_id ve brüt, ücret ile net tutarları içeren her bakiye işlemi için bir satır verir. Bir Dashboard ödeme özeti yalnızca seri toplamını kanıtlar. Otomatik ödemelerin etkinleştirilmediği durumlarda bunun yerine Bakiye raporunu kullanın.

Bir satıcıya yapılan transfer gider olarak kaydedilmeli mi?

Hayır. Satıcının payı, müşteri ödemesi düştüğü anda bir borç haline gelir ve transfer bu borcu kapatır. Transferleri gider olarak kaydetmek, maliyeti mükerrer sayar ve satıcı borcunu kalibre edilmemiş şekilde yüksek gösterir.

İçe aktarıcının kategorisini tanımadığı bir Stripe satısına ne olur?

Varsayılan olarak 4440 olan mutabakat bekletme hesabına (settlement suspense account) kaydedilir ve deftere kayıt yanıtı, oraya giden kategorileri adlandıran bir uyarı döndürür. Rezervler ve olağandışı düzeltmeler tipik olarak bu şekilde düşer ki bu kasıtlıdır: birinin nereye ait olduğuna karar vermesine kadar para görünür kalır ve yevmiye dengede kalır.

Daha sonraki bir ödemede sonuçlanan iadeler nasıl ele alınır?

Daha sonraki ödemenin kalem kalem raporunda bir refund satırı olarak gelirler ve daha önce eşleştirilmiş ödemenin charge_id değeri aracılığıyla orijinal ödemeyle eşleştirilirler. Ödeme düzeyindeki bir Payments dışa aktarımından türetilen bir iade bu durumda yalnızca bir yaklaşımdır, bu nedenle kalem kalem rapor daha güvenli kaynaktır.