Online tahsilat sisteminin mutabakat ve muhasebe tarafı nasıl kurulur

Ay kapandığında panelin gösterdiği tahsilat toplamı ile banka hesabına geçen tutar birbirini tutmaz. Bu bir hata değildir; iki kayıt farklı şeyi ölçer. Panel kartın onaylandığı anı yazar, banka ekstresi ise paranın hesaba geçtiği anı ve kesintiler sonrası net tutarı yazar. Mutabakat, bu iki kaydı aynı rakama zorlamak değil, aradaki farkın her kalemini adıyla açıklayabilmektir. Kurulumun tamamı da buna bakar: farkı ay sonunda aramak yerine, işlem doğarken belli hale getirmek.

Panel toplamı ile banka hesabına geçen tutar neden ayrılır

Farkın ilk nedeni yapısaldır. Tahsilat.com bir ödeme kuruluşu ya da elektronik para kuruluşu değildir; 6563 sayılı Kanun kapsamında aracı hizmet sağlayıcı sıfatıyla yalnızca teknik ödeme altyapısını kurar. Tahsil edilen bedel süreç boyunca bu altyapının hesaplarında beklemez, üye işyeri adına tanımlanan sanal POS üzerinden doğrudan işletmenin kendi banka hesabına aktarılır. Mutabakat açısından sonucu şudur: karşılaştıracağınız iki kayıt, panelin işlem dökümü ile kendi banka ekstrenizdir. Arada bakiyesi takip edilecek üçüncü bir cüzdan yoktur. Panel işlemin kanıtını tutar, para sizin hesabınıza gider.

Geriye kalan farklar zamanlama ve kalem farklarıdır. Bunlar sayılabilir ve her biri kendi yöntemiyle kapatılır.

Bu kalemler tek tek kapatıldığında geriye anlamlı bir fark kalmaz. Kapanmayan bir tutar hâlâ varsa sorun genellikle listenin kendisinde değil, işlemi tanımlayan kaydın eksikliğindedir.

Kanal bazlı döküm mutabakatta ne işe yarar

Bir farkın kapanabilmesi, o farkın nereden geldiğini gösteren bir kırılıma bağlıdır. Kanal bu kırılımların en işlevlisidir, çünkü tahsilatın nasıl doğduğunu söyler.

Aynı işletme bir ay içinde sitesinin ödeme adımından, müşteriye gönderdiği ödeme linkinden, SMS ile istediği ödemeden, tezgahtaki QR koddan ve tekrarlayan abonelik tahsilatından para alabilir. Kayıtta yalnızca kart tahsilatı yazıyorsa, ay sonunda eksik çıkan tutarın bir adresi yoktur; beş akışın hepsini birden gözden geçirmek gerekir. Kanal bilgisini her işlemin üzerinde taşıyan bir çok kanallı online tahsilat sistemi ise aynı farkı tek bir akışa indirger ve kontrol edilecek kayıt sayısını belirgin biçimde küçültür.

Kırılımın ikinci faydası doğrudan muhasebe tarafındadır. Hasılatı kanal bazında ayırabilen bir kayıt düzeni, hangi satış biçiminin ne ürettiğini gösterir. Abonelik gibi tekrar eden tahsilatları tek seferlik satışlardan ayırmak da bu sayede mümkün olur. İki kalem aynı toplamın içinde eridiğinde dönemler arası karşılaştırma anlamını yitirir.

Üçüncüsü iade tarafını görünür kılar. İadelerin hangi kanalda yoğunlaştığı tek bir toplam rakamın içinde saklı kalır. Kanal kırılımı bunu ayrı bir satır haline getirir ve geri dönüşlerin satış biçiminden mi yoksa ürünün kendisinden mi kaynaklandığını ayırt etmeye yarar.

Mutabakat ay sonunda değil, ödeme talebi anında kurulur

Mutabakat bir ay sonu işlemi gibi görünür, ama sonucu ödeme talebinin oluşturulduğu anda belirlenir. İşlem kaydı hangi bilgiyi taşıyorsa ay sonunda o bilgiyle eşleştirme yapabilirsiniz. Taşımıyorsa geriye tek bir yöntem kalır: tutar üzerinden tahmin yürütmek. Bu yöntem de aynı fiyatlı iki satış olduğu anda bozulur.

Ödeme talebi oluşturulurken işleme iliştirilmesi gereken alanlar şunlardır.

• Kendi kayıt numaranız: sipariş, fatura veya cari numaranız işleme iliştirilsin. Ay sonunda eşleştirmenin dayanağı bu alandır.
• Kanal bilgisi: işlemin siteden mi, linkten mi, SMS talebinden mi yoksa abonelikten mi doğduğu kayıtta yazılı olsun.
• Ortak müşteri anahtarı: aynı müşterinin farklı kanallardan yaptığı ödemeleri tek cari altında toplayabilmek için tüm kanallarda aynı anahtar kullanılsın.
• İşlem referansı: bankaya ve panele giden referans kendi sisteminizde de saklansın. İade ve itiraz süreçlerinde aranan tek bağ budur.
• Tutar ve taksit ayrımı: brüt tutar ile taksit adedi ayrı alanlarda dursun. Tek bir toplam alanı, taksitli satışlarda ekstredeki hareketle eşleşmeyi zorlaştırır.

Bu alanlar kurulum sırasında bir defa tanımlanır. Sonradan eklemek, geçmiş işlemlere geri dönüp elle eşleştirme yapmak anlamına gelir. Geliştirici tarafında API dokümantasyonu, hazır SDK ve sandbox ortamı bulunması, alanların canlıya çıkmadan denenmesini mümkün kılar. Webhook test araçları da bildirimlerin kendi sisteminize doğru düştüğünü ilk işlemden önce görmenizi sağlar.

İade ve iptal kayıtları asıl işlemle nasıl eşleşir

İade ile iptal aynı şey değildir ve mutabakatta farklı yerlere düşer. Genel işleyişte iptal, gün sonuna kapanmadan geri alınan tahsilattır; kart sahibinin ekstresinde bir hareket bırakmaz ve işletmenin banka hesabına hiç ulaşmaz. İade ise gün sonuna girmiş, yani hesaba geçmiş ya da geçecek bir tahsilatın geri verilmesidir ve kart sahibine ayrı bir alacak olarak yansır. Gün sonu saatleri ve iade süreleri bankadan bankaya değişebildiği için bir işlemin hangi kategoriye düştüğünü kendi sanal POS sözleşmenizden teyit etmek gerekir.

Eşleşmeyi kuran şey tutar değil, asıl işlemin referansıdır. İade kaydı asıl işleme bağlıysa üç soruyu tek bakışta cevaplarsınız: hangi satış geri döndü, hangi kanaldan gelmişti, hangi cariye aitti. Bağlı değilse elinizde yalnızca hesabınızdan çıkmış bir tutar kalır ve o tutarı doğrulamak için sipariş kayıtlarını elle taramak gerekir.

Kısmi iadede fark daha da belirginleşir. Asıl işlemin bir bölümü geri verildiğinde panel iki kaydı ayrı ayrı gösterir; banka tarafında ise iade çoğu kez günlük aktarımın içinde netlenmiş olarak görünür. Bu davranış bankaya göre değişebildiğinden kendi ekstrenizde nasıl göründüğünü bir kez doğrulamak gerekir. Doğrulandıktan sonra okuma yönü nettir: ay sonu toplamını ekstreden geriye doğru çözmeye çalışmak yanıltır, panel dökümünden ekstreye gitmek doğru sonucu verir.

Muhasebe tarafında iade yeni bir gider kalemi değildir; asıl satışa bağlı bir düzeltmedir. Bu düzeltmenin hangi hesaba ve hangi döneme yazılacağı işletmenin muhasebe düzenine ve tabi olduğu mevzuata göre değişir, dolayısıyla kaydın biçimini mali müşavirinizle birlikte belirleyin.

Muhasebe aktarımı hangi düzende kurulur

Önce bir sınırı netleştirmek gerekir. B2B ve B2C tarafındaki ürün muhasebe entegrasyonlarını içermez; tahsilat kayıtları muhasebe programınıza kendiliğinden düşmez. Aktarımı işletme kendi tarafında kurar, ister kayıtları dönemsel olarak aktararak ister kendi sistemine bağlanarak. Hangi yol seçilirse seçilsin sıra aynıdır.

1. Hesap karşılıklarını tanımlayın. Tahsilat hasılatı, banka komisyonu gideri, iade düzeltmesi ve varsa aylık paket ücreti için hangi hesapların kullanılacağı aktarım başlamadan belli olsun.
2. Eşleştirme anahtarını seçin. Aktarımda hangi alanın anahtar olacağına karar verin; genellikle kendi sipariş veya fatura numaranız bu işi görür, işlem referansı ise doğrulama için yanında taşınır.
3. Aktarım yönünü kurun. Kayıtlar kendi sisteminize webhook ile anlık düşecekse bildirimlerin karşılandığını, dönemsel olarak çekilecekse çağrının hangi aralıkta çalışacağını belirleyin. Her iki kurgu da canlıya çıkmadan sandbox ortamında denenebilir.
4. Brütü ve kesintiyi ayırın. Hasılatı brüt tutardan yazın, banka komisyonunu ayrı gider satırında gösterin. Net tutarı hasılat olarak kaydetmek komisyonu görünmez kılar ve maliyet takibini bozar.
5. Mutabakat frekansını belirleyin. İşlem adedi düşükse aylık kontrol yeter; kanal ve banka sayısı arttıkça haftalık ya da günlük kontrol daha yönetilebilirdir. Eşik ciro değil, elle düzeltilen kayıt sayısıdır.
6. İstisnaları yazılı hale getirin. İade, kısmi iade, iptal, onaylanmayan işlem ve yabancı para birimindeki tahsilat için hangi kaydın açılacağı bir kez yazılsın. Bu liste olmadan aynı durum her ay farklı kişi tarafından farklı kaydedilir.

Komisyon, paket ücreti ve vergi tarafındaki sınır

Muhasebe kaydında en sık karışan üç kalem birbirinden ayrı durur ve ayrı satırlara yazılır.

İşlem başına kesilen banka komisyonu, işletmenin kendi bankasıyla yaptığı sanal POS sözleşmesine göre belirlenir. Altyapı sağlayıcısının tek başına saptadığı bir oran değildir. Başvuru tarafında yayımlanan “%0,79’dan başlayan oranlar” ifadesi de bir başlangıç seviyesini anlatır, her işletmeye uygulanan sabit bir oran değildir; gider bütçesini bu ifadeye göre kurmak yerine sözleşmenizdeki gerçek orana göre kurun.

Aylık paket ücreti ise ayrı bir kalemdir ve yalnızca Pos Yönlendirme ile B2B bayi tahsilatı kullanımına aittir. Yalnızca sanal POS başvurusu yapan bir işletme bu satırı hiç görmez. Paket kullanılıyorsa ücret işlem başına değil sabit aylık gider olarak kaydedilir; Pro için 2.500 TRY ve Pro+ için 3.500 TRY tutarları KDV hariç yayımlandığından KDV gider kaydında ayrı satır olarak yer alır. Paket limitleri işlem adedi ve işlem tutarı üzerinedir, bağlanan banka ya da POS sayısı bu limitin konusu değildir. Kurulum ücreti ve taahhüt bulunmaması, ücretlendirmenin başarılı işlemler üzerinden yapılması nedeniyle başlangıçta kaydedilecek ayrı bir kurulum gideri de oluşmaz.

Vergi tarafı bu düzenin dışındadır ve öyle kalması gerekir. Buradaki anlatım genel bilgilendirmedir, vergi danışmanlığı yerine geçmez. Tahsilatın hangi dönemde hasılat sayılacağı, verginin hangi anda doğduğu, iadenin hangi belgeyle düzeltileceği ve yabancı para birimindeki işlemin hangi kurla kaydedileceği mevzuata bağlı sorulardır; mevzuat da zaman içinde değişebilir. Bu soruların cevabını mali müşavirinizden alın. Mutabakat düzeninin görevi vergi kararı vermek değil, o kararı verecek kişiye eksiksiz ve birbirine eşleşmiş bir kayıt seti teslim etmektir.

Bu düzen kime gerekli, kime erken

Her işletmenin bu ayrıntıda bir mutabakat kurgusuna ihtiyacı yoktur. Tek kanaldan, tek bankaya, ayda az sayıda tahsilat alan bir işletme için panel dökümüne bakıp ekstreyi gözle karşılaştırmak yeterlidir. Bu ölçekte ayrı bir aktarım kurmak, çözdüğünden fazla iş üretir.

Düzen şu üç işaretten en az ikisi göründüğünde gerekli hale gelir: tahsilat birden fazla kanaldan geliyorsa, birden fazla bankada sanal POS varsa, iade ve abonelik gibi tekrar eden hareketler kayıtta yer tutuyorsa. Bu noktadan sonra elle eşleştirme hem yavaşlar hem de hata payı taşımaya başlar.

Kurulum kararını verirken bakılacak eşik ciro değildir. Ay sonunda kaç kaydı elle düzelttiğinizi sayın. O sayı aydan aya düşmüyorsa sorun muhasebe tarafında değil, işlemin doğduğu andaki kayıt eksikliğindedir. Düzeltme, ay sonu tablosunda değil ödeme talebinin kurulduğu ekranda yapılır.

Sık sorulan sorular

Taksitli satışta banka aktarımı tek seferde mi gelir

Bu, işletmenin bankasıyla yaptığı sanal POS sözleşmesine bağlıdır ve ödeme altyapısı tarafından belirlenmez. Mutabakat kurgusunu kurmadan önce bankanızın taksitli işlemlerde aktarımı nasıl yaptığını yazılı olarak teyit edin. Panelin brüt kaydı sabittir, ekstredeki hareketin ritmi ise bu cevaba göre değişir; ikisini eşleştiren tabloyu da o ritme göre kurmak gerekir.

Birden fazla bankada sanal POS varsa mutabakat tek listeden yürütülebilir mi

İşlemleri tek listede izlemek mümkündür, ancak eşleştirme banka kırılımında yapılır. Her banka kendi ekstresini üretir ve komisyon koşulları da bankaya göre değişir. Tek liste günlük takip için, banka kırılımı ise mutabakat için kullanılır. Paket limitleri işlem adedi ve tutarı üzerinden işlediğinden, bağlanan banka veya POS sayısı bu tarafta ayrı bir kısıt oluşturmaz.

Onaylanmayan işlemler mutabakatta ne olur

Onaylanmayan işlem tahsilat değildir; hasılata girmez ve banka ekstresinde karşılığı bulunmaz. Buna rağmen kaydı silmeyin. Başarısız deneme, siparişin neden tamamlanmadığını gösteren tek izdir ve müşteri sonradan ödediğinde aynı sipariş numarası üzerinden ikinci denemeyle eşleşerek tek bir satışın tam hikayesini verir.