B2B E-Ticarette Doğrudan Borçlandırma Sistemi (DBS) ve Sanal POS Mutabakatı

B2B e-ticarette tahsilat, ödeme ekranında “başarılı” sonucunun alınmasıyla tamamlanmaz. Siparişin ERP’ye aktarılması, müşterinin cari hesabına işlenmesi, DBS riskinin kullanılması veya kart işleminin provizyondan geçmesi, komisyonun hesaplanması ve net tutarın banka hesabına ulaşması farklı zamanlarda gerçekleşebilir. İade, iptal, parçalı teslimat, taksit ve ters ibraz gibi durumlar eklendiğinde finans ekipleri aynı ticari işlemin birden fazla sistemdeki izini sürmek zorunda kalır.

Sağlıklı bir mutabakat yapısı, DBS ve sanal POS’u yalnızca alternatif ödeme yöntemleri olarak değil; sipariş, tahsilat, cari hesap ve banka hareketleri arasında ilişki kuran uçtan uca bir veri süreci olarak ele alır. Amaç her kaydın neden eşleştiğini açıklayabilmek, farkları sorumlu ekiplere yönlendirmek ve yapılan müdahaleleri denetim iziyle saklamaktır.

DBS ve sanal POS B2B tahsilatta nasıl konumlanır?

Doğrudan Borçlandırma Sistemi, ana firmanın bayi veya distribütörden doğan alacağını banka üzerinden tahsil etmesine yönelik bir yapıdır. Banka tarafından bayiye tanımlanan limit, uygun faturaların belirli koşullarla garanti kapsamına alınmasında ve vadesinde tahsil edilmesinde kullanılır. Örneğin Akbank’ın DBS açıklaması, fatura bilgilerinin internet bankacılığı, sFTP veya web servisiyle aktarılabildiğini ve tutarın bayi limiti üzerinden bloke edilerek vadede ana firmaya ödenebildiğini belirtir. Kesin işleyiş, limit kullanımı ve garanti koşulları çalışılan bankanın sözleşmesine göre değerlendirilmelidir.

Sanal POS ise B2B müşterinin kartla tek çekim veya taksitli ödeme yapabilmesini sağlar. İşlem önce yetkilendirilir; ardından bankanın ya da ödeme hizmeti sağlayıcısının takvimine göre üye işyeri hesabına aktarılır. Brüt satış tutarı ile hesaba geçen net tutar aynı olmayabilir. Komisyon, taksit maliyeti, hizmet bedeli, bloke süresi, valör, iade veya ters ibraz bu farkın bileşenleri olabilir.

İki kanalın birlikte sunulduğu bir portalda müşterinin kullanılabilir DBS riski, siparişin ödeme koşulu ve kartla tahsil edilebilecek tutar açık biçimde yönetilmelidir. Aksi hâlde aynı sipariş için iki tahsilat girişimi, yanlış risk rezervasyonu veya kapatılamayan cari hesap bakiyesi oluşabilir.

DBS limiti ile cari limit aynı veri değildir

DBS toplam limiti, bankanın bayi lehine tanımladığı çerçeveyi; kullanılabilir limit ise mevcut blokeler ve riskler sonrasında kullanılabilecek kısmı ifade eder. ERP’deki cari limit, vadesi geçmiş bakiye veya şirket içi risk sınıfı ise kurumun ticari politikasına aittir. Sipariş kabul kararı bu verilerin tek bir “limit” alanında birleştirilmesiyle değil, kaynağı ve güncellik zamanı belli ayrı kontrollerle verilmelidir.

Portal, bankadan gelen kullanılabilir riski gösterirken son sorgu zamanını ve verinin kesinlik durumunu da taşımalıdır. Banka servisine ulaşılamadığında eski limit bilgisini kesin değer gibi kullanmak yerine siparişi beklemeye almak veya yetkili onaya yönlendirmek daha kontrollü bir yaklaşımdır.

Uçtan uca tahsilat ve mutabakat akışı

Mutabakatın başlangıç noktası banka ekstresi değil, sipariş anında üretilen değişmez işlem kimliğidir. Sipariş numarası; ödeme denemesi, DBS talimatı, sanal POS işlemi, ERP belgesi ve banka hareketiyle ilişkilendirilir. Sağlayıcı işlem numaraları korunur ancak kurum içi anahtarın yerine geçirilmez. Böylece sağlayıcı değişse bile kayıt zinciri sürdürülebilir.

1. Sipariş ve ödeme seçiminin kaydedilmesi

Sistem müşteri, şirket, para birimi, sipariş tutarı, vade, ödeme kanalı ve sepet sürümünü kaydeder. DBS seçilmişse bayi-bankası ve limit sorgusu; sanal POS seçilmişse terminal, kart programı, taksit ve ödeme denemesi bilgileri ilişkilendirilir. Yenilenen sayfa veya zaman aşımı nedeniyle oluşan tekrarların ikinci tahsilata dönüşmemesi için benzersiz istek anahtarı kullanılmalıdır.

2. Yetkilendirme ile finansal tahsilatın ayrılması

Sanal POS’taki başarılı provizyon, paranın banka hesabına geçtiği anlamına gelmez. Benzer biçimde DBS talimatının kabul edilmesi de vade günündeki kesin finansal sonucu tek başına göstermez. Veri modelinde “istek alındı”, “yetkilendirildi”, “risk ayrıldı”, “tahsile gönderildi”, “hesaba geçti”, “iade edildi” ve “itirazlı” gibi durumlar ayrı tutulmalıdır.

3. ERP ve cari hesaba kontrollü aktarım

Ödeme sonucu, sipariş ve fatura kayıtlarıyla aynı ticari bağlamda ERP’ye iletilmelidir. Aktarımın ağ hatası nedeniyle tekrar edilmesi mükerrer muhasebe fişi üretmemelidir. ERP belge numarası, kayıt zamanı ve kabul veya hata cevabı entegrasyon günlüğünde saklanmalıdır. Cari hesap bakiyesi, tahsilat kesinleşmeden kurum politikasına aykırı biçimde kapatılmamalıdır.

4. Sağlayıcı raporu ve banka hareketinin alınması

Bankadan veya ödeme sağlayıcısından işlem, komisyon, taksit, valör ve iade dosyaları API, web servisi ya da kontrollü dosya aktarımıyla alınabilir. Her dosyanın kaynağı, dönemi, sürümü ve alınma zamanı kaydedilmelidir. Aynı rapor yeniden geldiğinde sistem kayıtları çoğaltmamalı; değişiklik varsa yeni sürümü önceki hâliyle karşılaştırmalıdır.

5. Eşleştirme, fark kuyruğu ve kapanış

Sistem önce güçlü anahtarları, ardından kontrollü yardımcı kuralları kullanır. Sipariş numarası, sağlayıcı işlem kimliği ve ERP belge numarası güçlü eşleştirme alanlarıdır. Tutar, tarih ve açıklama benzerliği tek başına kesin eşleşme sayılmamalıdır. Tam eşleşen kayıtlar otomatik kapanırken belirsiz veya farklı sonuçlar inceleme kuyruğuna aktarılır.

Sanal POS mutabakatında hangi alanlar eşleştirilmelidir?

Yalnızca brüt işlem tutarını karşılaştırmak, sanal POS mutabakatı için yetersizdir. İşlem para birimi, terminal, taksit sayısı, komisyon oranı ve tutarı, beklenen valör tarihi, net ödeme, iade ve ters ibraz ilişkileri de kontrol edilmelidir. Sağlayıcı raporundaki her hareket, mümkünse ilk satış işlemine kadar izlenebilmelidir.

• Sipariş ve ödeme denemesi numarası
• Sağlayıcı işlem, provizyon ve referans numarası
• Brüt satış tutarı ve para birimi
• Taksit sayısı, komisyon ve diğer kesintiler
• Beklenen ve gerçekleşen valör tarihi
• Banka hesabına geçen net tutar
• İptal, kısmi veya tam iade bağlantısı
• Ters ibraz tutarı, nedeni ve mevcut durumu

Ödeme hizmetlerinin Türkiye’deki düzenleyici çerçevesi 6493 sayılı Kanun ve ilgili ikincil düzenlemelerle şekillenir. Kuruluş ve faaliyet kapsamı değerlendirilirken TCMB’nin ödeme hizmetleri sayfasındaki güncel düzenleme ve yetkilendirme bilgileri esas alınmalıdır. B2B platformu ödeme hizmeti sağlayıcısı gibi konumlanmamalı; sözleşmeli banka veya yetkili sağlayıcıdan gelen kayıtları kendi sipariş ve muhasebe verileriyle bütünleştirmelidir.

İade ve ters ibraz aynı süreç değildir

İade, satıcı tarafından başlatılan ve ilk satışla ilişkilendirilen finansal işlemdir. Ters ibraz ise kart işleminin itiraz süreci sonucunda geri alınması riskini ifade eder. Bu nedenle ikisi aynı durum koduyla kapatılmamalıdır. Kısmi iadede kalan tahsilat tutarı korunmalı; ters ibrazda itiraz nedeni, belge son tarihi, savunma dosyaları ve sonuç ayrıca izlenmelidir.

Ters ibrazın ilk siparişten haftalar sonra gelmesi mümkündür. Daha önce “tam eşleşti” olarak kapanan dönemin sessizce değiştirilmesi yerine düzeltme hareketi açılmalı, ilgili cari hesaba etkisi gösterilmeli ve gerekiyorsa finans onayına sunulmalıdır. Başvuru ve yanıt süreleri ödeme kuruluşu, kart ağı ve sözleşmeye göre değişebileceği için yazılımda sabit varsayılmamalı, yapılandırılabilir olmalıdır.

Farklar nasıl sınıflandırılmalı ve yönetilmelidir?

Mutabakat ekranı yalnızca eşleşmeyen kayıtların uzun bir listesini sunarsa operasyon ekibi kök nedeni bulmakta zorlanır. Her fark türü; beklenen aksiyon, sorumlu rol, önem seviyesi ve çözüm süresiyle tanımlanmalıdır. Böylece sistem teknik hata ile ticari istisnayı birbirinden ayırabilir.

• Eksik kayıt: POS’ta görünen işlemin ERP’de veya sipariş sisteminde bulunmaması.
• Tutar farkı: Brüt, komisyon, iade ya da net ödeme tutarlarının beklenen değerle uyuşmaması.
• Tarih farkı: Valör veya hesaba geçiş tarihinin sözleşmedeki takvimden sapması.
• Durum farkı: Portalda başarılı görünen işlemin sağlayıcıda iptal, iade veya itirazlı olması.
• DBS risk farkı: Portalın kullandığı risk ile bankanın güncel kullanılabilir limitinin uyuşmaması.
• Mükerrer kayıt: Aynı ticari olayın birden fazla ödeme veya muhasebe kaydı üretmesi.

Kural motoru, kesin eşleşme ile önerilen eşleşmeyi ayırmalıdır. Kullanıcı öneriyi kabul ettiğinde hangi iki kaydı, hangi gerekçeyle bağladığı saklanmalıdır. Manuel kapatma açıklamasız yapılamamalı; yüksek tutarlı farklarda ikinci onay aranmalıdır. Cari hesap tarafındaki daha geniş yaklaşım için cari mutabakat yazılımı rehberi incelenebilir.

Yetki, onay ve denetim izi nasıl kurulmalıdır?

Finans, satış, operasyon ve bilgi teknolojileri ekiplerinin aynı verilere erişmesi, herkesin aynı işlemleri yapabilmesi anlamına gelmemelidir. Satış ekibi sipariş ve müşteri bağlamını görebilirken banka hesabı ayrıntıları sınırlandırılabilir. Operasyon iade talebi açabilir; belirli tutarın üzerindeki iade finans yöneticisi tarafından onaylanabilir. Sistem yöneticisi entegrasyon ayarlarını değiştirebilir ancak finansal farkı tek başına kapatamayabilir.

Onay akışı tutar, ödeme kanalı, şirket, para birimi ve istisna türüne göre çalışabilir. Reddetme, yeniden değerlendirme, vekâlet ve süre aşımı durumları da tasarlanmalıdır. Sipariş tarafındaki rol ve limit kurgusu için B2B siparişlerde onay akışı yaklaşımı tahsilat kararlarına uyarlanabilir.

Denetim izi; önceki ve sonraki değerleri, işlemi yapan kullanıcıyı, zamanı, gerekçeyi ve varsa onay kaydını içermelidir. Entegrasyondan gelen ham kayıt ile kullanıcı tarafından düzeltilmiş iş kaydı ayrılmalı; kaynak veri geriye dönük olarak görünmez biçimde değiştirilmemelidir.

Güvenlik ve entegrasyon mimarisinde temel kontroller

Kart verisinin gereksiz yere B2B platformuna alınmaması, güvenlik kapsamını azaltan temel mimari kararlardan biridir. Ödeme sayfası, tokenizasyon ve saklı kart gibi seçenekler banka veya yetkili sağlayıcının çözümleriyle tasarlanmalıdır. PCI Security Standards Council, PCI DSS standardını ödeme hesabı verisini korumaya yönelik teknik ve operasyonel gerekliliklerin temeli olarak tanımlar. Kart sahibine ait hassas veriler mutabakat amacıyla ERP’ye veya raporlama tablolarına kopyalanmamalıdır.

• Servis hesapları ve kullanıcılar için en az yetki ilkesi uygulanmalıdır.
• API anahtarları ve sertifikalar güvenli kasalarda tutulmalı, düzenli yenilenmelidir.
• Aktarım kanalları şifrelenmeli; dosya bütünlüğü ve kaynak doğruluğu kontrol edilmelidir.
• Kişisel ve finansal alanlar ekran, dışa aktarım ve günlüklerde maskelenmelidir.
• Webhook ve servis çağrılarında imza, zaman damgası ve tekrar oynatma kontrolleri kullanılmalıdır.
• Hata günlükleri kart verisi veya erişim sırrı içermemelidir.

Entegrasyonlar geçici kesintileri olağan kabul eden bir kuyruk yapısıyla çalışmalıdır. Başarısız çağrı kontrollü olarak yeniden denenmeli, tekrar sınırı aşıldığında teknik hata kuyruğuna düşmeli ve sorumlu ekibe bildirilmelidir. İzleme panelleri yalnızca servis erişimini değil, iş sonucunu da ölçmelidir: bankadan dosya gelmemesi, POS kayıtlarının ERP’ye aktarılamaması veya beklenen valörde ödeme bulunmaması ayrı uyarılar üretmelidir.

Projeye özel B2B mutabakat yazılımı nasıl planlanır?

Hazır bir entegrasyon konektörü veri taşıyabilir; ancak kurumun limit politikası, cari hesap yapısı, çoklu şirket düzeni ve onay sorumluluklarını tek başına çözmez. Analiz çalışmasında siparişten banka hareketine kadar tüm olaylar, veri sahipleri ve istisnalar çıkarılmalıdır. Hangi sistemin müşteri, sipariş, fatura, tahsilat ve muhasebe kaydı için ana kaynak olduğu açıkça belirlenmelidir.

İlk sürümde sınırlı sayıda banka, terminal ve ERP şirketiyle pilot yapılması; otomatik kapanış oranı kadar yanlış eşleşme riskinin de izlenmesi yararlıdır. Kurallar gerçek işlem örnekleriyle doğrulandıktan sonra diğer kanallara yayılabilir. Kullanıcı kabul testleri normal satışların yanında kısmi iade, zaman aşımı, yinelenen bildirim, eksik dosya, valör kayması ve ters ibraz senaryolarını da kapsamalıdır.

Kumsal Ajans; iş süreçleri, kullanıcı rolleri, veri sahipliği ve entegrasyon gereksinimlerine göre projeye özel B2B e-ticaret ve web yazılımı çözümleri geliştirir. ERP, banka/DBS ve sanal POS bağlantıları; sipariş, tahsilat, iade ve cari hesap kayıtlarını ortak fakat izlenebilir bir veri yapısında buluşturacak şekilde planlanabilir.

Sonuç: Mutabakat, ödeme sonrası bir rapor değil süreç tasarımıdır

B2B e-ticarette DBS ve sanal POS mutabakatının hedefi yalnızca toplam tutarların eşit çıkması değildir. Güvenilir yapı; kullanılan DBS riskini, kart işleminin yaşam döngüsünü, komisyon ve valörü, banka hesabına geçen net tutarı, iadeyi ve ters ibrazı aynı sipariş zincirinde açıklayabilmelidir. Otomatik eşleşme operasyon yükünü azaltırken fark kuyruğu, yetkili onay ve denetim izi kontrolü korur.

B2B tahsilat ve mutabakat sürecinizdeki banka, sanal POS, ERP ve sipariş akışlarını birlikte analiz etmek; kuruma özel entegrasyon ve yönetim yapısını planlamak için Kumsal Ajans ile iletişime geçin.