Ödeme Mutabakatı Nedir? PSP Ödemelerini Deftere Eşleme
Bir Stripe ödemesinin neden hiçbir zaman faturalarınızla uyuşmadığını, bir hak edişin satış, komisyon ve iadelere nasıl ayrılabileceğini ve defter kayıtlarının pratikte nasıl çalıştığını inceleyin."
Ödeme mutabakatı (payment reconciliation), bir ödeme hizmeti sağlayıcısının (PSP) size fiilen ödediği tutar ile müşterilerinizin size fiilen borçlu olduğu tutarı eşleştirmektir. Bu, banka mutabakatından farklı bir konudur ve daha zordur; çünkü bir PSP hak edişi hiçbir zaman tek bir fatura için yapılan tek bir ödeme değildir.
Bunun en belirgin göstergesi şudur: 10.000 € satış yapmışsınızdır ancak bankaya 9.712,40 € gelmiştir. Her iki rakam da doğrudur. Aradaki farkı açıklayan süreç, bu mutabakattır.
Ödeme neden satışlarla asla uyuşmaz?
Tek bir Stripe, Adyen veya PayPal ödemesi net bir toplu işlemdir (net batch). Müşterinin ödeme yapması ile paranın hesaba geçmesi arasındaki süreçte PSP şunları yapar:
- Bir mutabakat dönemi içindeki birçok tahsilatı toplar,
- İşlem başına kendi komisyonlarını düşer,
- Aynı zaman penceresinde gerçekleşen iadeleri ve ters ibrazları (chargeback) düşer,
- Muhtemelen bir rezerv tutarı alıkoyar,
- Kalan tutarı günler sonra tek bir transferle öder.
Böylece banka ekstresinde tek bir satır görünür (9.712,40 €), ancak defterde hiçbiri bu tutarla eşleşmeyen onlarca fatura yer alır. Ödemeyi doğrudan faturalarla eşleştirmek imkansızdır; öncelikle ödemenin bileşenlerine ayrıştırılması gerekir.
Ayrıştırma süreci
Bir hak ediş grubu kategorilere ayrılır ve her kategori defter için farklı bir anlama gelir:
| Kategori | Ne anlama gelir | Defter etkisi |
|---|---|---|
| Tahsilatlar (Charges) | Müşteri ödemeleri | Alacakları kapatır |
| İadeler (Refunds) | Müşterilere iade edilen para | Kapanmış bir alacağı tersine çevirir |
| Komisyonlar (Fees) | PSP'nin komisyonu | Bir giderdir |
| Ters İbrahimler (Chargebacks) | Geri alınan itirazlı ödemeler | Bir alacağı yeniden açar, ayrıca bir komisyon doğurur |
| Düzeltmeler / Rezervler (Adjustments / reserves) | Zamanlama ve risk kesintileri | PSP tarafından borçlanılan bir bakiye |
Sağlanması gereken matematiksel eşitlik şudur:
Brüt tahsilatlar − iadeler − komisyonlar − ters ibrazlar ± düzeltmeler = Net ödeme
Eğer bu eşitlik sağlanmıyorsa, toplu dosya eksik içe aktarılmıştır. Bu kontrol, herhangi bir tekil eşleştirmeden çok daha değerlidir; çünkü hiçbir verinin sessizce kaybolmadığını kanıtlar.
Muhasebe kayıtları
10.000 € brüt tahsilat, 250 € komisyon ve 37,60 € iade içeren bir hak ediş grubunun kayda alınması:
| Hesap | Borç | Alacak |
|---|---|---|
| 2710 Bankalar | 9.712,40 | |
| 6800 Finansal Giderler (PSP komisyonları) | 250,00 | |
| 5000 Gelir / alacak düzeltmesi (İadeler) | 37,60 | |
| 2410 Ticari Alacaklar | 10.000,00 |
Şu şekilde okuyabilirsiniz: Müşterilerin 10.000 € tutarındaki borçları kapanmış, PSP 250 € kesinti yapmış, 37,60 € müşterilere geri dönmüş ve 9.712,40 € bankaya ulaşmıştır. Komisyon, hiçbir müşteri faturasında görünmeyen gerçek bir giderdir; brüt gelir ile banka mevduatlarının birbirinden sapmasının ve yalnızca banka satırı üzerinden mutabakat yapmanın hem geliri hem de maliyetleri neden sessizce düşük göstermesinin tam nedeni de budura.
Pazaryerleri (marketplaces) için bir katman daha vardır. Eğer hak ediş satıcılara ait parayı içeriyorsa, platformun geliri yalnızca kendi komisyonudur; kalanı ise bir borçtur (liability). Nordlet'in muhasebeleştirme kuralları (posting rules) bunu özel anahtarlarla ele alır: settlements.fees, settlements.commissionRevenue, settlements.sellerPayable ve settlements.suspense. Böylece bölünmüş bir ödeme; komisyonu gelir olarak, satıcının payını ise platform gelirini şişirmek yerine bir borç hesabına kaydeder.
Nordlet bunu nasıl yapar?
Süreç üç uç noktadan (endpoint) oluşur:
- İçe Aktarma (Import).
POST /v1/bank/settlements/importuç noktası, bir Stripe ödeme mutabakat raporunu okur ve her satırı kendi kategorisini taşıyan, alttaki her bir işlemle eşleşen bir hak ediş grubu oluşturur (sağlayıcı, hak ediş ID'si, para birimi, brüt, komisyonlar ve net). Gruplar sağlayıcı ve hak ediş ID'si başına benzersizdir; bu nedenle aynı raporun tekrar içe aktarılması mükerrer kayda neden olamaz. - Eşleştirme (Match).
POST /v1/bank/settlements/matchuç noktası, tahsilat ve iade satırlarını ait oldukları satış faturalarıyla ilişkilendirir. Satırlarunmatched(eşleşmemiş),matched(rapordaki sipariş veya fatura referansından otomatik olarak çözümlenmiş) veyamanual(bir insan tarafından belirlenmiş) eşleşme durumuna sahiptir. Komisyon ve düzeltme satırları tasarımları gereği faturalarla eşleştirilemez; bunu denemek tahmin yürütülerek değil, reddedilir. - Muhasebeleştirme (Post).
POST /v1/bank/settlements/postuç noktası, yukarıdaki muhasebeleştirme kuralları aracılığıyla tüm grubun defter kayıtlarını yazar ve grup durumunuimported(içe aktarıldı) durumundanposted(muhasebeleştirildi) durumuna getirir. Eşleşmeyen tahsilatlar bir faturaya zorla bağlanmak yerine bir nazım hesaba (suspense account) düşer; bunlar görünürdür ve çözülene kadar bilerek rahatsız edici kalır.
Şirketin baz para biriminden farklı bir para birimindeki ödeme, manuel bir müdahaleye gerek kalmadan muhasebeleştirilir. Yevmiye kaydı baz para biriminde yazılır: grup, muhasebeleştirme tarihindeki kur üzerinden çevrilir, alacaklar her faturanın kesildiği andaki kur üzerinden kapatılır ve iki kur arasındaki kalıntı gerçekleşen kur farkı karı veya zararı olarak kaydedilir. Hala reddedilen tek durum, satırları birden fazla para birimini karıştıran tek bir ödemedir.
Muhasebeleştirilen grup, gerçek banka hesabındaki gelen banka ekstresi satırına bağlanır. Banka → Eşleştirme kuralları altında, bir ödemenin ekstrenizde nasıl göründüğünü tanımlarsınız: satırın her zaman içerdiği metin ve isteğe bağlı olarak içindeki ödeme ID'sinin ön eki. Bir ekstre içe aktarıldığında, bir kurala uyan satır, ödeme ID'siyle veya belirlediğiniz bir tarih penceresi içinde grubun net toplamıyla eşleştirilerek kendi grubuna bağlanır. Banka satırı, ikinci ve mükerrer bir muhasebe kaydı beklemek yerine bu sayede doğrudan mutabakatın yevmiye kaydını taşır; POST /v1/bank/settlements/link ve /unlink uç noktaları ise bağlantıyı elle kurar veya düzeltir.
Süreci doğru yürütmek için ipuçları
- Ay bazında değil, ödeme bazında mutabakat yapın. Ödeme, doğal birimdir; mutabakat yapmadan önce bir aylık ödemeleri toplulaştırmak, hataların bulunmasını sağlayan mutabakat eşitliğini ortadan kaldırır.
- Net tutarı asla gelir olarak kaydetmeyin. Bu, platform muhasebesinde yapılan en yaygın hatadır: 9.712,40 € geliri deftere kaydetmek hem satışları hem de giderleri düşük gösterir, brüt kar marjını bozar ve genellikle KDV'yi eksik bildirmenize yol açar; çünkü KDV, PSP'nin aktardığı tutar üzerinden değil, müşterinin ödediği brüt tutar üzerinden hesaplanır.
- Zamanlama farkına dikkat edin. 30 Haziran'da alınan ve 3 Temmuz'da ödemesi yapılan bir ödeme, Haziran ayının gelirine ve Temmuz ayının nakdine aittir. Dönem sonunda aradaki fark PSP'den alacak olarak durur (başkasının hesabında bulunan gerçek paradır).
- İadeleri orijinal satışla eşleştirin. Bağlantısı kurulmayan bir iade, kapanmış bir faturanın ödenmiş görünmesine ve gelirlerin yüksek raporlanmasına neden olur.
FAQ
Ödeme mutabakatı ile banka mutabakatı arasındaki fark nedir?
Banka mutabakatı, defterinizi banka ekstresiyle satır satır karşılaştırır. Ödeme mutabakatı ise bir adım daha önde yer alır: tek bir PSP ödemesini arkasındaki çok sayıda tahsilat, iade ve komisyona ayrıştırır, böylece banka satırları anlam kazanabilir.
Stripe ödemem satışlarımla neden uyuşmuyor?
Çünkü bir ödeme net bir toplu işlemdir: brüt tahsilatlardan komisyonlar, iadeler, ters ibrazlar ve olası rezervler düşülür; fatura tarihine göre değil, PSP'nin takvimine göre ödenir. Bu iki rakamın mutabakatı için bu bileşenlerin her birinin ayrı ayrı hesaba katılması gerekir.
PSP komisyonları gelir mahsup (netting) edilmeli mi?
Hayır. Gelir, müşterinin ödediği brüt tutardır; PSP komisyonu ise bunu tahsil etmenin bir gideridir. Bunları mahsup etmek hem geliri hem de giderleri olduğundan düşük gösterir, marjları bozar ve genellikle KDV işlemlerini yanlış yönlendirir.
Pazaryeri paylaşımları nasıl ele alınır?
Platformun geliri kendi komisyonudur; satıcının payı ise ödemesi yapılana kadar bir borçtur. Tüm ödemeyi gelir olarak kaydetmek, platformun kazancını aşırı derecede yüksek gösterir; komisyon geliri ve satıcı borçları için ayrı muhasebeleştirme kurallarının var olma nedeni tam olarak bunları ayrı tutmaktır.
Eşleşmeyen ödeme satırlarına ne olur?
Bir faturaya zorla bağlanmak yerine nazım hesaba (suspense account) kaydedilirler. Bu, defterin dengede kalmasını ve sorunun görünür olmasını sağlar; nazım hesap bakiyesi bir yapılacaklar listesidir ve dönem kapanmadan önce sıfırlanmalıdır.