Ay kapanışında saatler harcanan yer çoğu zaman tahsilatın kendisi değil, tahsilatın izini sürmektir. Kart ödemesi saniyeler içinde biter; o ödemenin hangi kanaldan geldiği, hangi siparişe ait olduğu, sonradan iade edilip edilmediği ve banka hesabına hangi tutarla düştüğü ise ancak kayıt düzeni kurulmuşsa cevaplanabilir. Kayıt düzeni, e tahsilat sisteminde her işlemin kendi kimliği, kanalı, tutarı ve sonraki hareketleriyle birlikte tek bir izde toplanmasıdır.

Bu düzen birkaç tanım kararına bakar ve o kararlar sistem kurulurken verilir. Sonradan kurulmaya çalışıldığında iş, veri düzenlemekten çıkıp geriye dönük veri tamamlamaya döner.

Bir tahsilat kaydının taşıması gereken alanlar

Kayıt düzeninin temeli, tek bir işlemin ne kadar eksiksiz saklandığıdır. Toplam ciro raporu ay sonunda bir sayı verir; sorunlu tek bir tahsilatı çözmek gerektiğinde o sayının içinden çıkılmaz. Aşağıdaki alanlar bir işlemi kendi başına anlaşılır kılar ve sonraki her kontrolü mümkün hale getirir.

• İşlem kimliği: sistemin ürettiği tekil numara, bankanın onay kodu ve işletmenin kendi sipariş numarası birlikte tutulur. Bu üçü birbirine bağlanmazsa takip zinciri ilk itirazda kopar.

• Kanal: tahsilatın sanal POS, ödeme linki, SMS, e-posta, QR kod ya da abonelik yenilemesi hangisinden geldiği.

• Tutar, para birimi ve taksit: TRY, USD, EUR ve GBP dahil 20+ para biriminden hangisiyle alındığı, 12 taksit imkanı içinde kaç taksit seçildiği.

• Kart türü: Visa, Mastercard, Troy ve American Express ayrımı. Kart numarasının kendisi saklanmaz, tokenization ile üretilen referans saklanır.

• Durum: başarılı, başarısız, iptal edilmiş veya iade edilmiş. Durum değiştiğinde eski kayıt silinmez, üzerine yeni hareket yazılır.

• Zaman: işlemin gerçekleştiği an ile bankaya iletim anı ayrı ayrı tutulur.

• Müşteri referansı: KVKK ve GDPR çerçevesinde işlemi bağlamaya yetecek kadarı, fazlası değil.

Bu alanların çoğu ödeme altyapısı tarafında zaten üretilir. Kurulumda verilen karar, hangisinin işletmenin kendi kayıtlarına da geçeceğidir. Sipariş numarası gibi işletmeye ait bir alan işlem açılırken gönderilmezse, o tahsilatı kendi satış kaydıyla eşleştirmek sonradan elle yapılan bir işe dönüşür.

İptal ile iade aynı kayıt değildir

Kart ödemelerinde geri dönüşün iki ayrı yolu vardır ve ikisi kayıtta farklı görünür. İptal, işlem banka tarafında kesinleşmeden geri alındığında oluşur; ortada tamamlanmış bir tahsilat kalmaz. İade ise tahsilat tamamlandıktan sonra tutarın müşteriye geri gönderilmesidir; ilk işlemi silmez, ters yönde ikinci bir hareket yaratır. Nakit akışında, mutabakatta ve muhasebe kaydında bu iki durum aynı yere yazılmaz.

İkisinin sınırı ve süresi işletmenin bankasıyla yaptığı sanal POS sözleşmesine göre değişir. Bir işlemin hangi saate kadar iptal edilebileceği ve iadenin kaç günde hesaba yansıyacağı altyapı tarafında değil, banka tarafında belirlenir. Kayıt düzeni açısından belirleyici olan hangi düğmeye basıldığı değil, o hareketin kendi tarihi ve kendi tutarıyla ayrı bir satır olarak saklanmasıdır.

Kısmi iadede bu daha da kritik hale gelir. Tek satırda güncellenen bir tutar, ay sonunda hangi kısmın ne zaman geri gittiğini gösteremez. Aynı işlem üzerinde birden fazla kısmi iade olabileceği için her geri dönüşün kendi satırını açması gerekir.

Kanal bazlı döküm: toplam cironun gizlediği bilgi

Çok kanallı tahsilatta toplam ciro tek başına yanıltıcıdır. Aynı ayda site üzerinden gelen sepet ödemeleri, mesajla gönderilen ödeme linkleri, SMS ile istenen bakiye tahsilatları ve abonelik yenilemeleri tek toplamda birleştiğinde hangi kanalın gerçekten çalıştığı görünmez.

Kanal ayrımı, raporun sonradan filtrelenmesiyle değil, işlem açılırken kaydın içine yazılmasıyla oluşur. Bu yüzden kanal etiketlerinin nasıl kurgulanacağı, e tahsilat sistemi kurulumu sırasında verilmesi gereken kararlardan biridir. Etiket şeması ilk günden oturmadığında, geçmiş ayın işlemlerini kanala göre ayırmak elle yapılan bir sınıflama işine döner.

Kanal bazlı döküm üç somut soruyu cevaplar:

1. Hangi kanal daha çok tamamlanmayan işlem üretiyor? Başarısız işlemin kanalı bilinmiyorsa sorunun ödeme adımında mı yoksa gönderim biçiminde mi olduğu ayırt edilemez.

2. Hangi kanalda iade yoğunlaşıyor? İade eğilimi çoğu zaman ürünün kendisiyle değil, satışın yapıldığı ortamla ve müşterinin ödeme anındaki bilgi düzeyiyle ilgilidir.

3. Hangi kanal hangi taksit ve kart türünü çekiyor? Taksit dağılımı ve kart türü kanaldan kanala aynı çıkmaz, bu da fiyatlama ve kampanya kararını etkiler.

Abonelik tahsilatı bu ayrımın en net örneğidir. Tekrarlayan bir tahsilatta her dönem ayrı bir işlemdir; aynı müşteriye ait olmaları onları tek kayıt yapmaz. Dönemlerden biri başarısız olduğunda hangi ayın açıkta kaldığını görebilmek, ancak her dönem kendi satırında durursa mümkündür.

Tahsilat kaydı ile banka ekstresinin buluştuğu nokta

Kayıt zincirinin ikinci ayağı banka hesabıdır ve burada Tahsilat.com bir ara durak değildir. Marka teknik ödeme altyapısını sağlar; ödeme, üye işyeri adına tanımlanan sanal POS üzerinden doğrudan işletmenin kendi banka hesabına aktarılır ve bedel hiçbir aşamada altyapı sağlayıcısının hesabında beklemez. Bunun kayıt düzenine pratik yansıması şudur: sistemdeki işlem listesi ile banka ekstresi iki ayrı kaynaktır, ikisini birbirine bağlayan şey işlem kimliğidir.

Ertesi iş günü ödeme aktarımının çalıştığı bir kurguda hesaba düşen tutar, o günün işlem toplamıyla birebir aynı olmayabilir. Banka komisyonu, aynı gün içinde yapılan iadeler ve hafta sonuna denk gelen günler aradaki farkı açıklar. Bu farkın her ay yeniden araştırılmaması için kayıtta üç şeyin ayrı durması yeterlidir: brüt işlem tutarı, kesinti kalemleri ve hesaba geçen net tutar. Banka komisyon oranı işletmenin bankasıyla yaptığı sözleşmeye göre belirlendiği için bu kalem, altyapı ücretlendirmesinden ayrı bir satır olarak okunur.

Altyapı tarafında ücretlendirme yalnızca başarılı işlemler üzerinden yapıldığından, başarısız denemeler kesinti satırında görünmez. Bu da başarısız işlem kaydının bir maliyet kalemi değil, operasyon verisi olarak okunması gerektiği anlamına gelir.

Muhasebe çıktısının sınırı ve mali müşavirin alanı

Ödeme altyapısı kaydın oluştuğu yerdir; o kaydın muhasebe karşılığını kurmak ayrı bir iştir. Tahsilat.com tarafında B2B ve B2C ürünü muhasebe entegrasyonlarını içermez. Bu sınırı bilmek kurulum planını doğrudan değiştirir, çünkü işlem verisinin muhasebe programına hangi yolla taşınacağı ayrıca kararlaştırılmalıdır. Geliştirici tarafında API dokümantasyonu, hazır SDK, sandbox ortamı ve webhook test araçları bulunduğu için veriyi kendi sistemine akıtmak isteyen ekiplerin çalışabileceği bir zemin vardır; kod tarafına girmeyen işletmeler içinse dönemsel dışa aktarım pratik yol olarak kalır.

Buradaki anlatım genel bilgilendirme amaçlıdır ve vergi danışmanlığı yerine geçmez. Hangi tahsilatın hangi belgeyle kayda alınacağı, iadenin belge tarafında nasıl karşılanacağı ve dönem kapanışında hangi kalemin nereye yazılacağı işletmenin faaliyet konusuna ve mükellefiyet durumuna göre değişir; mevzuat da zaman içinde değişebilir. Bu başlıklarda doğru adres mali müşavirdir. Kayıt düzeninin amacı da zaten bunun tersi değildir: tahsilatın eksiksiz kayıt altına alınması bu düzenin çıkış noktasıdır, kaydı zayıflatan hiçbir kurgu operasyonel kolaylık sayılmaz.

Ay kapanışında kayıt düzeninin getirisi

Kayıt düzeninin karşılığı tahsilat anında değil, ay kapanışında görünür. Aynı veriyi sonradan toplamak mümkündür, ama maliyeti farklıdır. Kanal etiketi taşımayan bir işlem yığınını geriye dönük sınıflamak, o etiketi kurulumda tanımlamaktan kat kat uzun sürer ve her ay yeniden yapılır.

4. Banka ekstresindeki her satırın karşılığı işlem listesinde bulunur; açıklanamayan tutar kalmaz.

5. İade ve iptal kalemleri ayrı toplandığı için ay içindeki brüt ve net ciro farkı tek bakışta okunur.

6. Kanal bazlı döküm hazır olduğundan hangi satış biçiminin ne getirdiği tahmin konusu olmaktan çıkar.

7. Başarısız işlemler ayrı bir küme olarak durduğu için tekrar denenebilecek tahsilatlar gözden kaçmaz.

8. Mali müşavire giden dosya sorulara cevap veren bir dosya olur, ek soru turu ortadan kalkar.

Bu maddelerin hiçbiri ek bir yazılım gerektirmez. Kanal etiketi, işlem kimliği ve durum alanı kurulum sırasında tanımlandığında düzen kendiliğinden birikir. Verilmesi gereken tek karar, ilk tahsilat alınmadan önce bu üç alanın nasıl doldurulacağının netleşmesidir.

Sık sorulan sorular

Taksitli bir satış kayıtta kaç işlem sayılır

Müşteri tarafında tutar taksitlere bölünür, işletme tarafında ise tahsilat tek bir işlem olarak açılır ve taksit adedi o işlemin bir alanıdır. Tutarın işletme hesabına hangi düzende geçeceği bankayla yapılan sanal POS sözleşmesine bağlıdır. Ekstre ile işlem listesi arasındaki farkı çoğu zaman bu alan açıkladığı için taksit adedi kayıtta mutlaka saklanmalıdır.

Farklı para biriminde alınan tahsilat nasıl kaydedilir

20+ para birimiyle çalışan bir kurguda kaydın işlem para birimini, tutarı ve işlem anını olduğu gibi tutması gerekir. Türk lirası karşılığı bu üçünden türetilir, tersi mümkün değildir. Hangi kurun hangi tarih için esas alınacağı muhasebe tarafının kararıdır ve mali müşavirle netleştirilir.

Başarısız işlem kaydı tutmanın anlamı ne

Başarısız denemeler ücretlendirmeye girmez, ama bilgi taşır. Aynı müşterinin arka arkaya birkaç başarısız denemesi kart tarafındaki bir engeli, aynı kanalda toplanan başarısızlıklar ise gönderim veya yönlendirme tarafındaki bir aksaklığı gösterir. Bu kayıt tutulmadığında geriye yalnızca tamamlanan satışlar kalır ve kaybedilen tahsilatın nedeni hiç görünmez.

Kayıt düzeni kurulduktan sonra da değiştirilebilir mi

Yeni alan eklemek her zaman mümkündür, ancak eklenen alan yalnızca o andan sonraki işlemlerde dolar. Geçmiş kayıtlar boş kalır ve dönem karşılaştırmaları bozulur. Bu yüzden kanal, kimlik ve durum gibi karşılaştırmaya temel olan alanların baştan tanımlanması, sonradan eklenebilecek tanımlayıcı alanlardan daha önceliklidir.