Marketplace Seller Subledgers: Revenue vs Payables

Pazaryeri muhasebesindeki en yaygın hata, alıcının ödediği brüt tutarı platform geliri olarak kaydetmektir. Bir müşteri 100 euro öder, bu 100 euro ödeme kuruluşu hesabına yatar ve birisi tutarın tamamını satışlara kayleder. Bir süre hesaplar dengede görünür, gelirler harika görünür ve sonra bir denetçi satıcı borcunun nerede olduğunu sorar. Ortada borç yoktur, çünkü satıcının 90 eurosu hiçbir zaman borç olarak kaydedilmemiştir.

Bu sorunun çözümü kozmetik değil, yapıcısaldır. Bir pazaryeri; ilk kayıttan itibaren yolda olan müşteri nakdini, platform komisyon gelirini, satıcı borçlarını, masrafları ve karşılıkları (reserve) birbirinden ayıran bir defter (ledger) modeline ihtiyaç duyar. Ödemeler (payout), kendi başına bir gelir veya gider kalemi olmayıp, borcu kapatan altıncı bir işlemdir. Bu kılavuz, söz konusu havuzları ayrı tutan dengeli yevmiye kayıtlarını ve veri modelini göstermektedir.

Önce asıl (principal) ve aracı (agent) değerlendirmesiyle başlayın

Herhangi bir hesap yapısından önce, platform ne sattığına karar vermelidir. ASC 606 kapsamında bu durum, her bir belirli mal veya hizmet için ayrı ayrı değerlendirilir ve verilecek yanıt, gelirin brüt mü yoksa net mi olacağını belirler. Bir platform, bir akış için asıl satıcı, diğeri için aracı konumunda olabilir.

Tipik bir satıcı ürünü pazaryeri satışında, platform genellikle aracıdır. Satıcının ürününün alıcıya ulaşmasını sağlar, stok riskini üstlenmez ve kazancı bir komisyondur. Deloitte'un ASC 606 kapsamında asıl ve aracı rehberi (principal-versus-agent guidance under ASC 606), testi kontrol kavramı etrafında şekillendirir: taahhüdü yerine getirme sorumluluğu, stok riski ve fiyatlandırma takdiri, temel kontrol değerlendirmesini geçersiz kılan bir kontrol listesi değil, birer göstergedir.

Bunun sadece bir iç yazıda değil, defter tasarımında yer almasının nedeni, varılan sonucun sonraki tüm kayıtları tetiklemesidir. Platform aracıysa, satıcının payı kazanıldığı anda bir borçtur. Eğer sipariş karşılama veya garanti hizmeti için asıl satıcı konumundaysa, o kısım platform geliridir. Bu sonucu veri olarak saklayın:

• principal_agent_role
• specified_good_or_service
• commission_rule_id
• control_assessment_version
• effective_from / effective_to

İki yıl sonra net bir komisyon kalemini inceleyen bir denetçi, brüt tutarın neden kullanılmadığını görebilmelidir. BillingPlatform'un ASC 606 asıl ve aracı analizi üzerine makalesinde belirttiği gibi (BillingPlatform notes on ASC 606 principal vs agent), "pazaryeri" etiketi tek başına sorunu çözmez; kontrol analizi çözer.

Tek bir yevmiye kuralı yazmadan önce satıcı bakiyesini tanımlayın

"Satıcı bakiyesi" tek bir sayıdan ibaret değildir. Bir satıcı, genel toplamda yüksek bir bakiyeye sahip olabilir ancak para henüz beklemede (pending) olduğu veya karşılık olarak (reserve) tutulduğu için çekilebilir nakdi olmayabilir. Bu durumları birbirine karıştırırsanız, satıcının neyi çekebileceğini ve platformun ne kadar borçlu olduğunu yanlış raporlarsınız.

En azından şunları takip edin:

• Beklemede (Pending): Kazanılmış veya tahsil edilmiş, henüz ödemeye uygun olmayan
• Kullanılabilir (Available): Platform kurallarına göre ödemeye uygun olan
• Karşılık ayrılmış (Reserved): Beklenen iadeler, anlaşmazlıklar (dispute) veya ters ibrazlar (chargeback) için alıkonulan
• Ödenmiş (Paid out): Transfer edilmiş veya takas için gönderilmiş
• Negatif: Satıcının borçlu olduğu, gelecekteki tahsilatlardan mahsup edilecek tutar
• Muallakta (Suspense): Alınmış ancak satıcısı veya muhasebe muamelesi henüz kesinleşmemiş

Ödeme sağlayıcıları bu ayrımı halihazırda yapmaktadır. Stripe, bağlı her hesabı beklemede ve kullanılabilir bakiyeler olarak ayırır, belirli negatif satıcı bakiyeleri için ise platform düzeyinde ayrılmış bir karşılık bakiyesi tutar. Aracı kurum bu ayrımı yapıyorsa, defter de yapmak zorundadır; aksi takdirde mutabakat asla tutmaz.

Hesap planı ve önemli boyutlar (dimensions)

İşlevsel bir başlangıç yapısı; mahsup (clearing) hesaplarını, borçları ve gelirleri ayrı tutar ve her önemli kayıtta bir satıcı boyutu taşır.

Amaç	Hesap veya boyut	Muhasebe işlemi
Takas bekleyen ödeme kuruluşu fonları	Ödeme kuruluşu takas hesabı	Takas varlığı
Bankaya yatan ödeme kuruluşu ödemesi	Banka	Varlık
Kazanılmış ancak ödenmemiş satıcı tutarı	Satıcı borçları (payables)	Borç (Liability)
Satıcı düzeyinde detay	seller_id boyutu	Borç detayı, gelir değil
Platform komisyonu	Komisyon geliri	Gelir
KDV veya satış vergisi	Ödenecek vergi	Borç (Liability)
Ödeme kuruluşu masrafları	Ödeme işlem gideri	Gider
Satıcı karşılıkları	Karşılık borcu	Sözleşmeye bağlı
İadeler	Gelir düzeltici (contra-revenue) veya iade	Orijinal işlemi tersine çevirir
Ters ibrazlar (Chargebacks)	Zarar, alacak veya satıcıdan tahsilat	Zararı kimin üstlendiğine bağlıdır
Banka onayı bekleyen ödemeler	Satıcı ödeme takas hesabı	Takas hesabı
Dağıtılmamış tutarlar	Muallak (Suspense)	Geçici istisna

Her önemli kayıt; satıcı, sipariş, ödeme grubu, ödeme kuruluşu, para birimi, yasal varlık, vergi muamelesi, etkinlik türü, harici referans ve olası bir ters kayıt bağlantısını içermelidir. Bunlar olmadan, satıcı alt defteri (subledger) münferit bir bakiyeyi, genel defter (general ledger) ise toplamı kanıtlayamaz.

Alt defteri, her satıcı için ayrı bir borç hesabı, seller_id boyutuna sahip tek bir toplulaştırılmış borç hesabı ya da borç, karşılık ve ödeme takası arasında bölünmüş bir yapı olarak kurgulayabilirsiniz. Onlarca satıcıyı geçtikten sonra boyut içeren toplulaştırma yaklaşımı daha iyi ölçeklenir. Fonların nasıl sunulması gerektiğini fon koruma kuralları ve yerel ödeme mevzuatı etkileyebileceği için modeli muhasebecinizle birlikte seçin. Kayıt mekanikleri için, pazaryeri muhasebesi için çift taraflı defter API'leri konusundaki makalemiz, bu modelin üzerine oturduğu defter bileşenlerini ele almaktadır.

Satışı, ayrı satıcı ve platform kalemleriyle kaydedin

Aracı satışını ele alalım: Müşteri 100 euro öder, platform komisyonu 10 eurodur, satıcı 90 euro kazanır. Komisyon ve satıcı hak edişinin oluştuğu anda:

Hesap	Borç (Debit)	Alacak (Credit)
Ödeme kuruluşu takas hesabı	€100
Satıcı borçları - Satıcı A		€90
Komisyon geliri		€10

Önemli olan kontrol şudur: 90 euro bir geliri değil, borcu alacaklandırır. Platform 10 euroyu kayda geçirir. Bu, platformun satıcının tüm satış tutarını değil, komisyonunu gelir olarak kaydettiği, ASC 606'nın pazaryeri örneğinde ulaşılan sonuçtur.

Vergi ayrıca tahsil ediliyorsa, ödenecek vergi kalemini ekleyin ve vergi sonucuna göre satıcı veya platform rakamını azaltın. Kolaylık olsun diye vergiyi komisyona veya satıcı borcuna dahil etmeyin.

Ödeme kuruluşu kesintilerini gelir ve borç matematiğinin dışında tutun

Üç şey sürekli birbirine karıştırılır: platform komisyonu, ödeme kuruluşu kesintisi (processor fee) ve ödeme tutarı. Bunlar farklıdır ve farklı hesaplara etki eder.

Müşteri 100 euro öder, komisyon 10 eurodur, ödeme kuruluşu 3 euro kesinti yapar.

• Sözleşmede aksi belirtilmediği sürece komisyon geliri 10 euro olarak kalır.
• 3 euroluk ödeme kuruluşu kesintisi bir giderdir.
• Satıcı sözleşmesi işlem ücretini satıcının karşılayacağını belirtmiyorsa, satıcı borcu 90 eurodur. Yalnızca bu durumda tutar 87 euroya düşer ve satıcıya yansıtılan 3 euroluk eşleşen bir kayıt oluşur.

Bankaya yatan net 97 euroyu kaydetmek, brüt satışları, komisyonu ve kesintiyi tek hamlede yok eder. Ödeme mutabakatı referansımız da aynı noktaya dikkat çekmektedir: mutabakatı ayrıştırın, ödeme kuruluşu kesintilerini gider olarak ele alın ve net mevduatın asla gelirin yerini almasına izin vermeyin.

Kullanılabilirliği, karşılıkları ve ödemeleri ayrı olaylar olarak modelleyin

Paranın durumu, tahsilat ile net nakit arasında birkaç kez değişir. Her geçiş kendi kaydını hak eder ve bir karşılık asla gelirden yapılan açıklanamaz bir kesinti değildir.

Kullanılabilir fonlar karşılığa aktarıldığında:

Hesap	Borç (Debit)	Alacak (Credit)
Satıcı borçları - Satıcı A	€15
Satıcı karşılık borcu		€15

Karşılık serbest bırakıldığında, kaydı tersine çevirin. Satıcının toplam yükümlülüğü değişmemiş, ancak durumu değişmiştir. Stripe, karşılıkları artıran ve serbest bırakan karşılık işlemlerini ve uzun süredir devam eden negatif bakiyeler için tahsilat transferlerini belgeler; bu nedenle bunların tek bir mahsuplaşma kaydı yerine tanımlanabilir hesaplara ihtiyacı vardır.

Ödemeler kendi iki aşamalı işlemlerine sahiptir. Onay aşamasında:

Hesap	Borç (Debit)	Alacak (Credit)
Satıcı borçları - Satıcı A	€90
Satıcı ödeme takas hesabı		€90

Onaylanan banka mutabakatında:

Hesap	Borç (Debit)	Alacak (Credit)
Satıcı ödeme takas hesabı	€90
Banka		€90

Ödeme başarısız olursa, takas kaydını tersine çevirerek satıcı borcuna iade edin. Ödeme bir gider değil, borç tasfiyesidir. Bunu bir gider olarak ele almak, borcu halihazırda kaydetmiş olan satışa karşı çift sayıma yol açar. Stripe, ödeme durumunu (pending, in_transit, paid, failed, canceled) ve beklenen varış tarihini başlangıçtan itibaren ayırır ve bu tarihler tek bir zaman damgasında birleştirilmemelidir.

Sipariş-ödeme veri modeli

Alt defter, uygulamanın mevcut sipariş durumuna göre değil, olaylara (events) göre çalışır. Satıcıyı etkileyen her olay aynı zarf yapısını taşır:

• seller_id, event_id, order_id
• event_type (satış, iade, ters ibraz, karşılık tutma, karşılık serbest bırakma, ödeme, düzeltme)
• effective_date, posting_date
• currency, direction, gross, commission, fees, reserve
• refund_ref / dispute_ref
• payout_batch_id
• reversal_of
• source_status, idempotency_key

Değişken bir alanı saklamak yerine, kapanış bakiyesini bu olaylardan hesaplarsınız:

Satıcı kapanış bakiyesi
= açılış bakiyesi
+ satıcı alacakları
− satıcı borçları
− ödemeler
± karşılık hareketleri
± düzeltmeler

Yeniden denemelerin (retry) ve yinelenen webhock'ların bir satıcıya iki kez alacak kaydetmesini veya iki kez ödeme yapmasını önlemek için her harici olayın kalıcı bir işlem tektiplilik (idempotency) anahtarına ihtiyacı vardır. Çalışan kalıplar şunlardır:

• Satıcı yevmiye olayı: seller_id:order_id:event_type:version
• Ödeme grubu: processor:payout_id
• Ödeme kuruluşu olayı: processor:event_type:processor_event_id

Stripe'ın kendi webhook rehberi, yinelenen olayların gerçekleşebileceği konusunda uyarmaktadır, bu nedenle kopya tespiti isteğe bağlı değildir. Gönderilen kayıtlar değiştirilemez (immutable) kalır. Düzeltmeler, ters kayıt artı düzeltilmiş kayıt yoluyla yapılır ve reversal_of bağlantısını ve nedenini taşıyan kendi olay zarfınızdır. Defter kayıtları tutar, bağlantıyı tutmaz: Nordlet, API referansında yevmiye işlemleri için oluşturma, getirme ve listeleme (create, get and list) sunar, güncelleme veya silme sunmaz; dolayısıyla bir düzeltme asla bir düzenleme değil, her zaman yeni bir işlemdir.

İadeler ve ters ibrazlar asla askıda kalmaz, kök işleme bağlanır

Gelecek haftanın ödemesinde ortaya çıkan bir iade, asla o ödemeye iliştirilmiş yeni bir negatif satış olmamalıdır. Bunu orijinal işleve bağlayın ve orijinal satıcı payını koruyun. Sözleşmeye bağlı olarak:

• Sözleşme iade edilebilir kılıyorsa komisyonu tersine çevirin
• İadeyi satıcı üstleniyorsa satıcı borcunu borçlandırın (debit)
• Platform üstleniyorsa bir platform zarar hesabını borçlandırın
• Bir anlaşmazlık açıkken karşılığı artırın, çözüm durumunda serbest bırakın veya kullanın

Ödemeden sonraki ters ibrazlar (chargeback), negatif bakiyelerin ortaya çıktığı durumlardır. Satıcının parası çoktan gitmiştir, bu nedenle platform ya bunu gelecekteki tahsilatlardan geri alır ya da zararı üstlenir. Model, negatif satıcı bakiyelerine izin vermeli ve kurtarma kuralını tanımlamalıdır. Adyen'in pazaryeri raporlaması, iadelerin ve ters ibrazların hesap sahibi başına ayrı borç satırları oluşturduğunu gösterir; hedeflenmesi gereken ayrıntı düzeyi budur.

Ay bazında değil, ödeme bazında mutabakat yapın

Kayıt yapmadan önce her ödeme kuruluşu mutabakatını ayrıştırın ve bir ayı toplulaştırmak yerine her ödemeyi ayrı ayrı mutabakata varın:

Brüt tahsilatlar
− iadeler
− ödeme kuruluşu masrafları
− ters ibrazlar
± karşılıklar ve düzeltmeler
= net ödeme kuruluşu ödemesi

Ardından her satıcı ve para birimi için dört bakiyenin uyuştuğunu kanıtlayın: satıcı alt defteri, ödeme kuruluşunun satıcı bakiyesi, ödeme raporu ve banka takas hesabı. Bunlar farklılık gösterdiğinde, farkı sınıflandırın (zamanlama, eksik olay, kopya, yanlış atfalama, yanlış para birimi, başarısız ödeme, yanlış tarafa kaydedilen ters ibraz). Farkları netleştirmek, hataların birbirini dengelemesine ve bir sonraki döneme kapanışına taşınmasına yol açar.

Tam bir ayı toplulaştırmak, zamanlama farklarının birbirini götürmesine izin verir ve gerçek kopmaları gizler. Tutar ve tarihe göre değil; ödeme kimliğine (payout ID) ve işlem referansına göre eşleştirilen ödeme bazlı eşleştirme, bunları yakalar.

Yaygın hata modları

Hata modu	Neden sakıncalıdır?	Kontrol
Brüt müşteri ödemesinin gelir olarak kaydedilmesi	Geliri şişirir, satıcı borcunu gizler	Hak ediş anında borç ve komisyonu ayırın
Yalnızca net ödemelerin kaydedilmesi	Brüt tutarı, masrafları, iadeleri, karşılıkları kaybeder	Her mutabakatı ayrıştırın
Ödemenin gider olarak muhasebeleştirilmesi	Bir borç tasfiyesini yanlış gösterir	Ödemede satıcı borcunu borçlandırın (debit)
Tek bir satıcı bakiye alanı olması	Bekleyen, kullanılabilir, ayrılmış ve ödenmiş tutarları karıştırır	Bakiye durumlarını açıkça takip edin
Komisyonun ödeme anında hesaplanması	Gelir, ödeme takvimini takip eder	Komisyonu kazanıldığı anda tanıyın
Karşılığın gelir kesintisi olarak ele alınması	Zamanlamayı ve riski gizler	Tutma, serbest bırakma ve kullanmayı ayrı ayrı takip edin
İadenin en son ödemeye uygulanması	Sipariş atfını bozar	İadeyi orijinal işleme bağlayın
Kaydedilmiş girişlerin düzenlenmesi	Denetim izini yok eder	Tersine çevirin ve yeniden gönderin
Yeniden oynatılan webhook'lar	Yinelenen alacaklar ve ödemeler oluşturur	İşlem tektiplilik anahtarları, kopya tespiti
Yalnızca tutar ve tarihe göre eşleştirme	Farklı kalemler çakışır	Ödeme kimliği, işlem kimliği, satıcı ve para birimine göre eşleştirin

İlk olarak ne yapardım?

Hesap planına dokunmadan önce para akışını haritalandırın. Ödeme tahsilatından karşılık serbest bırakılmasına kadar her olayı yazın ve hangilerinin gelir yarattığını, hangilerinin borç yarattığını ve hangilerinin yalnızca durumu değiştirdiğini işaretleyin.

Ardından uçtan uca tek bir akış oluşturun ve dengede olduğunu kanıtlayın: normal bir satış, kısmi bir iade, ödeme sonrasında bir ters ibraz, tutulan ve serbest bırakılan bir karşılık ve başarısız bir ödeme. Bunları bilinen beklenen bakiyelerle çalıştırın. Satıcı borcu kontrol hesabı alt defterlerin toplamına eşitse, ödeme kuruluşu takas hesabı mutabakat raporuyla uyuşuyorsa ve banka mevduatı ödeme kimliğiyle uyuşuyorsa, çalışan bir iskeletiniz var demektir.

Dönem kilitlemesini, ancak ilk ay boş bir muallak bakiyesiyle sorunsuz bir şekilde kapandıktan sonra etkinleştirin. Çok erken kilitlemek sadece hataları dondurur.

Nordlet, bu doğrultudaki mutabakatları kutudan çıktığı gibi kaydeder: platformun komisyonu komisyon gelirine, satıcının payı satıcı borcuna, ödeme kuruluşu kesintileri ödeme işlem giderine ve henüz atfedilmemiş olanlar muallak hesaba gider. Defter dönemleri, siz bunları açıkça kilitleyene kadar açık kalır; böylece muallak sıfırlandığında ilk ay kapatılabilir. Özellikler sayfası, nelerin dahil olduğunu listelemektedir.

FAQ

Alıcının ödemesi hiçbir zaman platform geliri midir?

Yalnızca platformun asıl satıcı olduğu belirli mal veya hizmetler için. Bir satıcının mallarının satıldığı bir aracı pazaryerinde, gelir komisyondur ve satıcının payı bir borçtur. Bir platform, aynı siparişte bir karşılama hizmeti için asıl satıcı ve alttaki mallar için aracı olabilir; bu nedenle değerlendirme şirket bazında değil, belirli mal veya hizmet bazındadır.

Karşılıklar geliri azaltmalı mıdır?

Hayır. Karşılık bir zamanlama ve risk tahsisidir, gelir düzeltmesi değildir. Fonları tuttuğunuzda satıcı borcundan karşılık borcuna aktarın ve serbest bıraktığınızda tersine çevirin. Gelir ve komisyon, satıcının parasının şu anda karşılıkta olup olmasından etkilenmez.

Webhook yeniden denemelerinden kaynaklanan mükerrer ödemeleri nasıl durdurabilirim?

Ödeme grupları için processor:payout_id gibi her harici olaya bir işlem tektiplilik (idempotency) anahtarı ekleyin ve yazma sırasında yinelenen olayları tespit edin. Sağlayıcılar, yinelenen webhook teslimatlarının gerçekleştiğini açıkça uyarır, bu nedenle defter ikinci denemeyi yeniden göndermek yerine reddetmelidir.

Satıcı bakiyesi eksiye düşebilir mi?

Evet, model buna izin vermelidir. Satıcıya ödeme yapıldıktan sonra gelen bir ters ibraz, platformu satıcıdan bir alacakla veya üstlendiği bir zararla baş başa bırakır. Negatif bakiyeleri gizlemek yalnızca kaydedilmemiş bir yükümlülüğü gizler.

Neden aylık toplam yerine her ödemeyi ayrı ayrı mutabakata varmalıyım?

Çünkü bir ayı toplulaştırdığınızda zamanlama farkları ve hatalar birbirini götürür, böylece münferit işlemler yanlışken toplamlar tutabilir. Ödeme ve işlem kimliklerine göre eşleştirilen ödeme bazlı mutabakat, kapanıştan önce eksik olayları, kopyaları ve yanlış atfedilen ters ibrazları ortaya çıkarır.

İleri okuma

• Pazaryeri muhasebesi için çift taraflı defter API'leri
• Ödeme mutabakatı: PSP ödemelerini defterle eşleştirme
• ASC 606 asıl ve aracı hususları (Deloitte)