Finansal sistemlerde tartışmasız kural
Bakiye, kullanıcı tablosunda güncellenen bir kolon değil; değişmez hareket kayıtlarının toplamı olarak hesaplanan bir değerdir. Kolon yaklaşımında eşzamanlı iki işlem birbirini ezer, hatalı güncelleme geri alınamaz ve "bu bakiye neden bu?" sorusunun cevabı bulunamaz. Mimarinin ayrıntısını [fintech ledger mimarisi rehberimizde](/blog/fintech-rehberi) anlatıyoruz.
Kritik süreçler
- Çift kayıtlı defter: Her işlemin toplamı sıfır olan en az iki satır üretmesi; düzeltmenin silme değil ters kayıt (storno) ile yapılması.
- Para birimi hassasiyeti: Tutarların tam sayı olarak en küçük birimde saklanması, yuvarlama kuralının tek yerde tanımlanması.
- İşlem tekrarı koruması: Ağ zaman aşımında tekrarlanan isteğin ikinci bir işlem üretmemesi.
- Durum makinesi: Başlatıldı → yetkilendirildi → tahsil edildi → iade/ters ibraz geçişlerinin ve izin verilen önceki durumların tanımlanması.
- Mutabakat: Kendi defteriniz ile sağlayıcı/banka dosyasının günlük karşılaştırılması; kapanmayan kalemlerin kuyruk yaşının izlenmesi.
- Yetki ve kayıt: Kimin hangi işlemi hangi yetkiyle yaptığının, değerin neyden neye değiştiğinin değiştirilemez biçimde saklanması.
Hangi çözüm neye karşılık geliyor?
Ödeme, cüzdan ve başvuru süreçleri için [fintech yazılımı](/urunler/fintech), hesap hareketi ve tahsilat eşleştirme için [banka entegrasyonu](/urunler/banka-entegrasyonu), likidite yönetimi için [nakit akışı takibi](/urunler/nakit-akis), müşteri süreçleri için [CRM](/urunler/crm) kullanılır. Kurum içi entegrasyon katmanı [API ve sistem entegrasyonu](/cozumler/api-entegrasyonu), standart dışı ürünler [özel yazılım geliştirme](/cozumler/ozel-yazilim-gelistirme) kapsamındadır.
Kart verisi ve kapsam
En etkili güvenlik kararı, kart verisini hiç saklamamaktır. Sağlayıcı barındırmalı alan veya cihaz üzerinde tokenizasyon kullanıldığında hassas veri sizin sisteminizden geçmez ve uyum kapsamı belirgin biçimde daralır. Bu bir sertifikasyon iddiası değil, mimari bir tercihtir; nihai kapsam değerlendirmesi ilgili standardın gereklilikleri ve denetim süreciyle yapılır.
Nereden başlıyoruz?
Finans tarafında başlangıç durumu genellikle şudur: tahsilat bankadan gelir, muhasebeye elle işlenir, müşteri cari hesabı bir başka ekranda güncellenir. Üç kayıt arasındaki fark ay sonunda fark edilir ve mutabakat elle yapılır.
İlk çalışmanın çıktısı para hareketinin uçtan uca haritasıdır: para hangi kanaldan giriyor, hangi kimlikle geliyor (dekont açıklaması, referans numarası, sanal POS işlem kodu) ve hangi kayıtla eşleşmesi gerekiyor. Eşleştirme anahtarı tanımlanmadan otomatik mutabakat kurulamaz.
Veri modelinde net olması gerekenler
- Çift kayıtlı defter: Her hareket için borç ve alacak satırı; tek satırlı bakiye güncellemesi denetlenebilir değildir.
- İdempotency anahtarı: Aynı işlemin tekrar gönderilmesi hâlinde ikinci kez işlenmemesini sağlayan benzersiz anahtar.
- Eşleştirme anahtarı: Tahsilatın hangi fatura veya cari hareketle eşleşeceğini belirleyen referans; açıklama metni tek başına yetersizdir.
- İşlem durumu: Beklemede, başarılı, başarısız ve iptal durumlarının ayrı tutulması; "başarısız" ile "yanıt alınamadı" aynı şey değildir.
- Komisyon ve kesinti: Banka komisyonu, blokaj ve valör farkının ayrı kalemler olarak kaydı.
- Para birimi ve kur: İşlem para birimi, kayıt para birimi ve kullanılan kurun kaynağı/tarihi.
Devreye alma sırası
1. Defter ve kimlik: Hesap planı, çift kayıt yapısı, işlem durumları ve idempotency kuralı.
2. Banka bağlantısı: Hesap hareketi çekme, dekont ayrıştırma ve eşleştirme kuralları.
3. Ödeme kanalları: Sanal POS, taksit, iade ve kısmi iade akışları.
4. Mutabakat ve raporlama: Otomatik mutabakat, fark listesi, komisyon kontrolü ve nakit projeksiyonu.
Neyi ölçüyoruz?
- Otomatik eşleşen tahsilat oranı ve elle müdahale gereken kayıt sayısı
- Mutabakat farklarının türe göre dağılımı (bizde var/onlarda yok, tutar farkı, komisyon)
- İşlem durumu "yanıt alınamadı" olarak kalan kayıt sayısı ve çözülme süresi
- Valör ve blokaj nedeniyle beklemedeki tutar
- Tahsilat vadesine göre alacak yaşlandırması
Sık yapılan hatalar
- Bakiyeyi tek alanda güncellemek. Hareket geçmişi olmadan fark analizi yapılamaz, denetim izi kaybolur.
- İdempotency anahtarı kullanmamak. Ağ hatasında tekrarlanan istek çift kayıt üretir.
- Yanıtsız işlemi başarısız saymak. Karşı tarafta gerçekleşmiş bir işlem, bizde iptal görünür.
- Komisyonu tahsilat tutarına gömmek. Cari hesap eksik kapanır ve müşteriye yanlış bakiye görünür.
Sık sorulan sorular
Bakiyeyi hareketlerden hesaplamak yavaş olmaz mı?
Dönemsel kapanış bakiyeleri tutulur ve sorgu yalnızca son kapanıştan sonraki hareketleri ekler. Böylece hem hız hem izlenebilirlik korunur.
Bir işlemi silmek gerekirse ne yapılır?
Silinmez; ters kayıt oluşturulur ve orijinaliyle ilişkilendirilir. Finansal kayıtlarda geçmişi değiştirmek denetlenebilirliği ortadan kaldırır.
Mutabakat farkları nasıl sınıflandırılır?
Üç grupta: sizde var onlarda yok (yanıtı kaybolmuş işlem), onlarda var sizde yok (kaçan bildirim), ikisinde var tutar farklı (komisyon, yuvarlama, kur). Her grubun çözüm yolu farklıdır; ayrıntısını [banka entegrasyonu rehberinde](/blog/banka-entegrasyonu-rehberi) ele alıyoruz.
Hangi banka entegrasyon yöntemi tercih edilmeli?
Bankaya göre değişir: doğrudan API, dosya tabanlı (MT940 vb.) aktarım veya kurumsal internet şubesi üzerinden otomatik dışa aktarım. API en hızlı geri bildirimi verir, dosya tabanlı yöntem daha yaygın desteklenir. Seçim, bankanın sunduğu kanal ve gereken gecikme toleransına göre yapılır.
Sanal POS iadelerinde nelere dikkat edilmeli?
Kısmi iade, taksitli işlemin iadesi ve gün içi/gün sonrası iade farklı davranır. Her iade orijinal işlem referansına bağlanmalı ve kendi durum akışını taşımalıdır; iadeyi negatif satış olarak kaydetmek mutabakatı bozar.
Nakit projeksiyonu ne kadar ileriye kurulabilir?
Sözleşmeli tahsilat ve ödemeler için vade tarihleri bilindiğinden projeksiyon doğrudan hesaplanır. Tahmine dayalı kalemler ayrı bir senaryo katmanında tutulmalı ve raporda gerçekleşmiş ile tahmini ayrımı görünür olmalıdır; ikisi karıştığında projeksiyon karar üretmez.