Ödeme Mutabakatı ve Raporlama Nasıl Yapılır?
Ders 9 / 10 · 30 dakika okuma · İleri
Sipariş, ödeme işlemi, iade ve sağlayıcı tahsilat kayıtlarını eşleştirerek eksik, fazla, mükerrer veya yanlış durumdaki işlemleri tespit etmeyi ve mutabakat sürecini operasyonel kontrol mekanizmasına dönüştürmeyi öğrenin.
Bu Derste Öğrenecekleriniz
- ✓Sipariş, ödeme ve finansal tahsilat kayıtlarının neden ayrı kaynaklar olduğunu açıklamak
- ✓İşlem bazlı mutabakat anahtarlarını belirlemek
- ✓Brüt tahsilat, komisyon, iade ve net ödeme ilişkisini kontrol etmek
- ✓Eksik, mükerrer ve durum uyuşmazlığı vakalarını sınıflandırmak
- ✓Beklenen tahsilat ile gerçekleşen banka/sağlayıcı ödemesini karşılaştırmak
- ✓Mutabakat farklarını sahip, neden ve SLA ile yönetmek
- ✓Ödeme raporlarını finans ve operasyon kararlarına dönüştürmek
E-ticaret sisteminde 'ödendi' görünen sipariş ile bankaya geçen para aynı veri kaynağı değildir. Sipariş sistemi ticari olayı, ödeme sağlayıcısı ödeme işlemini, banka veya sağlayıcı ödeme raporu ise işletmeye aktarılan finansal sonucu gösterir. Mutabakat bu kayıtların birbirini doğrulamasıdır.
1. Mutabakatın veri kaynaklarını belirleyin
| Kaynak | Temel kayıt | Kontrol amacı |
|---|---|---|
| E-ticaret sistemi | Sipariş ve ödeme kaydı | Ne tahsil edilmesi gerekiyordu? |
| Ödeme sağlayıcısı | İşlem ve refund kayıtları | Gerçekte hangi ödeme işlemleri oluştu? |
| Sağlayıcı ödeme/settlement raporu | Komisyon ve net ödeme | İşletmeye ne aktarılması bekleniyor? |
| Banka hareketi | Gerçek para girişi | Beklenen ödeme hesaba geçti mi? |
2. İşlem bazlı ortak anahtar kullanın
Mutabakatın en güçlü hali, toplam tutar karşılaştırması yerine işlem bazlı eşleşmedir. İç ödeme ID, merchant reference, sağlayıcı transaction ID ve settlement referansı gibi alanlar veri kaynakları arasında izlenebilir zincir oluşturur.
Uyarı — Yalnız sipariş numarasına güvenmeyin
3. Önce ödeme işlemi mutabakatını yapın
İç sistemde başarılı görünen her ödeme sağlayıcı tarafında da aynı işlem ID, tutar ve para birimiyle başarılı olmalıdır. Sağlayıcıda başarılı görünen ancak iç sistemde başarısız/bekleyen kalan işlemler de tespit edilmelidir.
| İç sistem | Sağlayıcı | Sonuç |
|---|---|---|
| Başarılı | Başarılı | Eşleşti |
| Başarılı | Bulunamadı/başarısız | Kritik inceleme |
| Bekliyor/başarısız | Başarılı | Sipariş/tahsilat uyuşmazlığı |
| Başarılı 1 kayıt | Başarılı 2 işlem | Mükerrer ödeme incelemesi |
| Tutar A | Tutar B | Tutar uyuşmazlığı |
4. Refund kayıtlarını ayrı finansal olay olarak eşleştirin
İade, orijinal ödemenin durumunu silmek yerine ona bağlı yeni finansal olay olarak izlenmelidir. İç sistemde başarılı görünen refund, sağlayıcı raporunda aynı tutar ve referansla doğrulanmalıdır.
Örnek — Kısmi iade mutabakatı
5. Brüt işlemden net settlement'a köprü kurun
Sağlayıcının işletmeye aktardığı tutar, brüt satış toplamından farklı olabilir. Komisyonlar, iadeler ve sözleşmeye bağlı diğer finansal kalemler net ödemeyi etkileyebilir.
Beklenen net ödeme = Brüt uygun tahsilatlar - iadeler - sözleşmeye göre kesilen ücretler ± diğer doğrulanmış finansal kalemlerUyarı — Formülü sözleşmeye göre uyarlayın
6. Settlement ile banka hareketini eşleştirin
Sağlayıcı raporunda 185.000 TL net ödeme görünmesi paranın işletme hesabına gerçekten geçtiğini tek başına kanıtlamaz. Settlement referansı, ödeme tarihi ve banka hareketi birlikte kontrol edilmelidir.
Örnek — Beklenen ve gerçekleşen ödeme
7. Valör nedeniyle açık kayıtları yanlış fark saymayın
Henüz ödeme vadesi gelmemiş işlemler gerçek mutabakat farkı değildir. Sistem işlem tarihi, beklenen settlement tarihi ve gerçekleşen ödeme tarihini ayrı tutmalıdır.
| Durum | Sınıf |
|---|---|
| Vadesi gelmedi | Beklenen açık tahsilat |
| Vade geldi, ödeme yok | Gecikmiş settlement |
| Settlement var, banka eşleşmedi | Banka mutabakat farkı |
| Banka girişi var, settlement bulunamadı | Kaynak/referans incelemesi |
8. Farkları neden koduyla yönetin
- İç sistem durum uyuşmazlığı
- Sağlayıcı işlem kaydı eksik
- Tutar/para birimi farkı
- Mükerrer işlem
- Refund uyuşmazlığı
- Settlement gecikmesi
- Komisyon/ücret farkı
- Banka eşleşme problemi
- Referans/veri kalitesi problemi
Her farkın sahibi, açılış zamanı, önem seviyesi, beklenen çözüm süresi ve kapanış nedeni bulunmalıdır. Aksi halde mutabakat yalnız Excel'de kırmızı satırlar üretir.
9. Otomatik eşleşme ve manuel incelemeyi ayırın
Tam referans, tutar ve para birimi eşleşen kayıtlar otomatik kapatılabilir. Belirsiz, çoklu adaylı veya tolerans dışı farklar manuel incelemeye yönlendirilebilir. Otomatik eşleşme kuralı neden eşleştirdiğini açıklayabilmelidir.
10. Toleransı gerçek farkları gizlemek için kullanmayın
Yuvarlama veya sözleşmede tanımlı küçük farklar için kontrollü tolerans kullanılabilir. Ancak sistematik komisyon hatası veya eksik tahsilatı 'tolerans içinde' diyerek kapatmak finansal hatayı görünmez hale getirir.
11. Mutabakat KPI'larını oluşturun
| KPI | Ne ölçer? |
|---|---|
| Otomatik eşleşme oranı | Kayıtların ne kadarı insan müdahalesiz kapanıyor? |
| Açık fark adedi/tutarı | Çözülmemiş finansal risk |
| Ortalama çözüm süresi | Mutabakat operasyon hızı |
| Settlement gecikme oranı | Beklenen ödeme performansı |
| Refund fark oranı | İade kayıtlarının tutarlılığı |
| Mükerrer ödeme vakası | Ödeme akışı/idempotency problemi |
12. Yönetim raporunu işlem gerçeğinden üretin
Ödeme raporunda brüt hacim, başarılı işlem, refund, net tahsilat, komisyon/ücret, settlement ve açık farklar birbirinden ayrılmalıdır. Böylece 'satış yaptık' ile 'nakit hesabımıza geçti' aynı metrikmiş gibi sunulmaz.
İlgili çözüm: Ödeme Entegrasyonları
Şimdi Uygulayın
Uygulama Görevi — Günlük Ödeme Mutabakatı Tasarlayın
Bir günlük örnek veri için e-ticaret ödeme kaydı, sağlayıcı transaction raporu, refund raporu, settlement ve banka hareketi alanlarını belirleyin. Otomatik eşleşme anahtarlarını, fark neden kodlarını ve manuel inceleme kurallarını yazın.
| Kontrol | Eşleşme anahtarı | Başarılı koşul | Fark aksiyonu |
|---|---|---|---|
| İç ödeme ↔ sağlayıcı | … | … | … |
| Refund ↔ sağlayıcı | … | … | … |
| Settlement ↔ işlemler | … | … | … |
| Settlement ↔ banka | … | … | … |
İpucu — Kabul testi
Bu Derste Ne Öğrendik?
- ✓Ödeme mutabakatı yalnız ay sonunda toplam banka bakiyesine bakmak değildir.
- ✓Sipariş, ödeme denemesi, sağlayıcı işlem kaydı, iade ve işletmeye yapılan net ödeme mümkün olduğunca işlem bazında ilişkilendirilmelidir.
- ✓Mutabakat sistemi başarılı görünen ama sağlayıcıda bulunmayan işlemleri, tahsil edildiği halde siparişe yansımayan ödemeleri, mükerrer tahsilatları, iade uyuşmazlıklarını ve beklenen-net ödeme farklarını yakalamalıdır.