Bir müşterinin ödediği tutar, işletmenin banka hesabına geçen tutarla aynı olmak zorunda değildir. Komisyon, iade, itiraz, bloke ve ödeme takvimi araya girer. Mutabakatın amacı bu farkları görünmez kılmak değil; nedenini ve durumunu açıklayabilmektir.
Dört kaydı ayırarak başlayın
Sipariş müşterinin ne aldığını, ödeme tahsilat sonucunu, cüzdan hareketi bakiye değişimini, hakediş ise işletmeye ilişkin alacak hesabını anlatır. Bu kayıtların tek tabloda birbirinin yerine kullanılması sorun yaratır. Aralarındaki bağ ortak referanslarla kurulmalıdır. Her kaydın oluşma zamanı ve durumu korunur.
Örnek hesap: brütten nete
Varsayımsal 1.000 TL işlemde 30 TL komisyon tanımlıysa diğer kalemler yokken 970 TL net alacak oluşabilir. Ancak banka ödemesinin gerçekleşmesi farklı bir olaydır. İade veya başka kesinti varsa yeni kayıtlarla açıklanır. Bu oran örnektir; Onexa Teknoloji fiyatlandırması veya gerçek sağlayıcı teklifi değildir.
Eşleşmeyen kayıtlar için iş kuyruğu
Ödeme sağlayıcısında başarılı, uygulamada bekleyen görünen işlem destek tarafından elle başarılıya çevrilmemelidir. Önce referans, tutar, para birimi ve durum kaynağı karşılaştırılır. Düzeltilen kayıt için kim, ne zaman, neden bilgisi tutulur. Sorumlu ekip ve sonuçlandırma süresi tanımlanır.
Banka ve sağlayıcı verisiyle karşılaştırın
Federal Reserve’in ödeme raporu fonlara erişim ve mutabakat gecikmelerinin işletmeler için sorun olabildiğini gösterir. Yerel projede gerçek sağlayıcı dosyaları, hesap hareketleri ve sözleşmedeki ödeme takvimi ayrıca incelenir. Demo hakediş göstergesi bir banka ödeme talimatı değildir; operasyon tasarımını anlatan örnek alacak görünümüdür.
Kontrol listesi
Aynı günün satış raporu ile aynı günün banka girişini doğrudan karşılaştırmak yanıltıcı olabilir. Raporlar işlem tarihi ve değerleme tarihi ayrımını açıklamalıdır.
- Eksik ve mükerrer referanslar
- Tutar ve para birimi farkları
- İade ve komisyon ters kayıtları
- Bekleyen alacak ile ödenen tutarın ayrımı
Ay sonu kapanışında örnek inceleme
Bir işletmenin uygulama raporunda 100 satış, sağlayıcı raporunda 99 tahsilat ve banka girişinde daha düşük bir tutar olduğunu varsayalım. İlk adım sayıları elle eşitlemek değildir. Önce işlem referansları karşılaştırılır; eksik tahsilatın bekleyen mi, reddedilen mi olduğu bulunur. Banka tarafındaki fark için ödeme takvimi, iade ve komisyon kalemleri incelenir. Raporlar farklı zaman aralıkları kullanıyorsa bu durum ayrıca düzeltilir. Sonuçta her farkın açıklaması ve sorumlusu olmalıdır. Farklı kaynakları tek sayıya zorlamak yerine açıklanabilir kayıt yapısı kurmak, bir sonraki kapanışın daha az manuel işlemle yürütülmesine yardımcı olabilir.
- İşlem tarihi ile banka ödeme tarihini ayırın.
- Farkları neden ve sorumlu ekip bazında sınıflandırın.
- Düzeltmeyi eski kaydı silmeden izlenebilir tutun.
Onexa Teknoloji ile başlangıç
Önce örnek bir satış gününü uçtan uca inceleyin. Hangi kaydın hangi sistemden geldiğini ve güvenilir durum kaynağını belirleyin. Ardından rapor ve istisna kuyruğu tasarlanır. API Sandbox’ta sipariş ve hareketleri inceleyebilir; üretim mutabakat entegrasyonunu ayrıca kapsamlandırabilirsiniz.
Başvurduğumuz kaynaklar.
Kaynaklar 2 Kasım 2026 tarihinde incelenmiştir. Sektör örnekleri Onexa Teknoloji’nin çözüm tasarımlarıdır; araştırma pazarları ve tarihler ilgili bölümde belirtilir.
Aklınızdaki sorular.
Bu yazıdaki çözümü kendi işime nasıl uyarlayabilirim?＋
İlk adım mevcut müşteri yolculuğunu ve işlem kayıtlarını birlikte incelemektir. İlgili yetenek sayfasından örnek akışı deneyebilir, ardından entegrasyon ve pilot kapsamını Onexa Teknoloji ile değerlendirebilirsiniz.