Sanal POS Hakedişi ve Gün Sonu Mutabakatı Nasıl Yapılır?

Sanal POS mutabakatı, yazılımdaki başarılı ödeme kaydının banka tarafında hesaba geçen tutarla karşılaştırılmasıdır. İki taraf genelde birebir tutmaz: işlem gününde çekilen tutar, hesaba komisyon düşülmüş ve valör sonrası toplu olarak geçer. Mutabakatın işi, bu farkın beklenen bir fark mı yoksa kayıp bir tahsilat mı olduğunu göstermektir.

Sanal POS kurulumunun kendisini sanal pos entegrasyonu, iptal ve iade tarafını ise ayrı bir yazıda ele almıştık. Burada konu, ödeme alındıktan sonra paranın izini yazılım içinde sürmek.

Neden iki taraf birebir tutmaz?

Farkın birkaç doğal kaynağı var ve bunları bilmek, gerçek sorunu aramaya başlamadan önce listeyi kısaltır. Birincisi komisyon: hesaba geçen tutar işlem tutarından düşüktür. İkincisi valör: işlem bugünkü, hesap hareketi daha sonraki bir güne düşer. Üçüncüsü taksit: bir satış birden fazla hakediş satırına bölünebilir.

Dördüncüsü iptal ve iadeler: aynı gün yapılan bir iptal hakediş dosyasında ayrı bir satır olarak değil, net tutarın içinde görünebilir. Beşincisi provizyon ile satış ayrımı: bazı akışlarda tutar önce bloke edilir, satışa dönüşmesi ayrı bir adımdır. Bu beş kalem ayrıştırılmadan yapılan karşılaştırma her gün tutarsız çıkar ve bir süre sonra kimse okumaz.

Yazılımda hangi kayıtlar tutulmalı?

Mutabakatın mümkün olması için ödeme kaydında şu alanların bulunması gerekir:

• Kendi işlem kimliğimiz: ödeme isteğini açarken ürettiğimiz tekil numara.
• Bankanın işlem referansı: yanıtta dönen ve hakediş dosyasında da bulunan numara.
• İşlem tarihi ve saati: gün sonu kesiminin hangi tarafa düştüğünü anlamak için.
• Brüt tutar, para birimi ve taksit sayısı.
• Durum geçmişi: provizyon, satış, iptal, iade adımlarının her biri ayrı satır.
• Bağlı belge: hangi sipariş ya da faturaya ait olduğu.

Bu alanların en kritiği bankanın referans numarasıdır; eşleştirmenin tek güvenilir anahtarı odur. Tutar ve tarih üzerinden kurulan eşleştirme, aynı gün aynı tutarda iki satış olduğunda yanlış satırı tutar.

Kayıtların saklanma süresi de bir karardır. Mutabakat yalnızca dünün değil, geçmiş ayların da sorgulanabildiği bir kayıt kümesi gerektirir; çünkü bir iade işlemi satışın yapıldığı aydan çok sonra gelebilir ve o satışın hangi hakediş satırında kapandığı sorulur. Ödeme kayıtlarını belge kayıtlarıyla aynı ömürde tutmak, bu soruyu sonradan cevaplanabilir kılar.

Mutabakat akışı nasıl kurulur?

İşleyen bir düzen üç adımdan oluşur. İlk adımda hakediş ya da gün sonu dosyası düzenli olarak alınır ve ham hâliyle saklanır; yorumlanmış veri değil, gelen dosyanın kendisi. İkinci adımda her satır referans numarasıyla ödeme kaydına bağlanır. Üçüncü adımda eşleşmeyenler iki listeye ayrılır: bizde var bankada yok, bankada var bizde yok.

Bankada var, bizde yok: en tehlikeli satır

Listelerden ikincisi, yani bankada görünüp bizde karşılığı olmayan tahsilat, en çok dikkat isteyen durumdur. Çünkü müşteri parayı ödemiştir ama siparişi yazılımda açılmamış olabilir. Bunun klasik sebebi, ödeme sonucunun bize dönerken kaybolmasıdır: tarayıcı kapanır, dönüş adresi zaman aşımına düşer, kayıt yarım kalır.

Çözüm, dönüş adresine güvenmemek ve ödemenin sonucunu ayrıca sorgulamaktır. Yarım kalmış her ödeme kaydı için belirli bir süre sonra durum sorgusu çalıştırıldığında bu satırlar kendiliğinden kapanır. Yanıtın kaybolmasına karşı kurulan tekil anahtar düzenini mükerrer kayıt ve idempotency yazısında anlatmıştık; aynı anahtar burada mutabakatın da anahtarı oluyor.

Muhasebeye ne aktarılır?

Mutabakat yalnızca bir kontrol değil, muhasebe kaydının da kaynağıdır. Satış anında müşteri hesabı kapanır ve kart alacağı hesabı doğar; para hesaba geçtiğinde kart alacağı kapanır, banka ve komisyon gideri hesapları hareket görür. Bu üç adım ayrı ayrı kaydedilmezse komisyon gideri hiç görünmez ve banka bakiyesi tutmaz.

Mutabakat raporunun okunabilir olması için üç sayının yan yana durması yeterlidir: gün içinde başarılı görünen tahsilat toplamı, hakediş dosyasından eşleşen toplam ve eşleşmeyen satır sayısı. Üçüncü sayı sıfıra yakın kaldığı sürece ilk iki sayının farkı komisyon ve valörden gelir. Eşleşmeyen satır sayısı artmaya başladığında bakılacak yer banka değil, kendi tarafımızdaki yarım kalmış kayıtlardır.

Hangi hareketin hangi hesaba gideceği, muhasebe eşleme tablosunda tanımlanır. Taksitli satışta hakediş satırları farklı günlere düştüğü için kart alacağı hesabı bir süre açık kalır; bu beklenen bir durumdur ve mutabakat raporunda açık kalan satırların yaşı görünüyorsa sorun değildir.

Kısa kontrol listesi

• Her ödeme isteği kendi tekil işlem kimliğimizle açılıyor.
• Bankanın referans numarası kaydediliyor ve eşleştirme onun üzerinden yapılıyor.
• Provizyon, satış, iptal, iade ayrı durum satırları olarak tutuluyor.
• Gelen hakediş dosyası ham hâliyle saklanıyor.
• Yarım kalan ödemeler için durum sorgusu otomatik çalışıyor.
• Komisyon, muhasebede ayrı bir gider kalemi olarak kaydediliyor.

Özetle sanal POS mutabakatı, tek bir rakamı karşılaştırmak değil, tahsilatın her adımını ayrı kaydedip eşleştirmektir. KAV Yazılım bu akışı ödeme kaydı, hakediş eşleştirmesi ve muhasebe fişi olarak tek bir zincirde kuruyor. Komisyon oranı, valör süresi ve kesim saati gibi değerler bankanızla yaptığınız sözleşmede yazılıdır; yazılım bu değerleri tanım ekranından okur.