Giriş

Toptan satışta ödeme çoğu zaman tek bir adım değildir. Alıcı önce kapora gönderir, üretici malzemeyi ayırır, sevkiyat tarihi yaklaşınca kalan tutar için ikinci fatura oluşur. Finans ekibi ise her iki ödemenin hangi proforma faturaya, hangi alıcıya ve hangi teslimata ait olduğunu görmek ister. Stablecoin ile tahsilat değerlendirilirken asıl konu teknoloji tanımı değil; bu zincirin kontrol edilebilir biçimde kurulmasıdır.

Bu rehber, toptan satış ve ihracat yapan işletmeler için stablecoin tahsilatını operasyon açısından ele alır. Amaç mevcut tahsilat yöntemlerini kaldırmak değildir. İşletme, kendi hukukî, vergi ve muhasebe yükümlülüklerini yerel uzmanlarıyla değerlendirmeli; yeni yöntemi ancak sınırları belirlenmiş bir pilotla devreye almalıdır.

Tahsilat akışı tekliften sevkiyata nasıl kurulmalı?

Sağlıklı bir akış, satış temsilcisinin müşteriye yalnızca bir cüzdan bilgisi göndermesiyle başlamaz. Önce teklif veya sipariş numarası oluşur. Ardından işletme, kapora ya da kalan bakiye için ayrı bir proforma fatura düzenler. Her fatura için benzersiz bir ödeme talebi oluşturulur ve talep, satış sistemindeki müşteri ile sipariş kaydına bağlanır.

Ödeme talebinde şu bilgiler açık olmalıdır: fatura numarası, beklenen tutar, kabul edilen varlık ve ağ, son ödeme zamanı, müşteri adı veya kurum referansı ve destek kanalı. Müşterinin aynı ödeme bilgisini başka bir sipariş için kullanması ya da ödeme açıklamasını serbestçe yazması, ileride mutabakatı zorlaştırır.

Ödeme ağ üzerinde görüldüğünde satış ekibi hemen sevkiyat emri vermemelidir. İşletme önce kendi tanımladığı doğrulama durumunu beklemeli, ardından ödemeyi fatura ile eşleştirmeli ve istisna olup olmadığını kontrol etmelidir. “İşlem göründü” ile “ticari olarak ödeme onaylandı” aynı durum değildir.

Kapora ve bakiye için iki ayrı kayıt oluşturun

Toptan satışta tek bir tahsilat bağlantısını bütün sipariş için kullanmak kolay görünür, fakat kontrolü azaltır. Kapora ve bakiye farklı zamanlarda, farklı kişiler tarafından ve hatta farklı şartlarla ödenebilir. Her aşama için ayrı kayıt, hem müşteri iletişimini hem de ürün tahsisini netleştirir.

Kapora akışı

Kapora faturası, siparişin hangi ürünleri ve hangi miktarı için ayrıldığını belirtir. Ödeme onaylandığında sistem siparişi “stok ayrıldı” durumuna geçirir. Bu durum, “sevkiyata hazır” anlamına gelmez. Üretim, kalite kontrolü ve ihracat belgeleri kendi süreçlerinde devam eder.

Kalan bakiye akışı

Sevkiyata yakın aşamada ikinci bir ödeme talebi oluşturulur. Bu talep ilk faturanın numarasını taşıyabilir ama kendi benzersiz kimliğine sahip olmalıdır. İkinci ödeme onaylandığında finans ekibi kapora ve bakiye kayıtlarını aynı satış sözleşmesi altında görebilmelidir.

Bu yaklaşım küçük gibi görünen bir sorunu çözer: Alıcı kaporayı ödeyip bakiyeyi geciktirdiğinde ekip hangi miktarın gerçekten tahsil edildiğini ve hangi teslimatın beklemesi gerektiğini tek ekranda görebilir.

Stablecoin seçimi: müşteri tercihi değil, işletme politikası

Bir alıcı hangi varlığı kullanmak istediğini söyleyebilir; fakat işletme kabul edeceği varlıkları ve ağları kendi politikasıyla sınırlandırmalıdır. Açık uçlu seçenekler destek yükünü artırır. Yanlış ağ seçimi, çok küçük tutar, geç ödeme veya beklenmeyen bir varlık işlemi, satış ekibinin manuel inceleme yapmasına yol açar.

Politika hazırlanırken şu sorular yanıtlanmalıdır:

İşletme, bu soruların yanıtını ödeme sayfasına ve satış ekibinin e-posta şablonuna yansıtmalıdır. Teknik entegrasyon ancak bu kural setinin ardından anlamlı olur.

API ve fatura sürecinin rolü

Bir B2B işletmede ödeme, satış sisteminden kopuk olmamalıdır. Fatura ve API seçenekleri değerlendirilirken asıl soru şudur: Ödeme bilgisi, sipariş numarasıyla geri dönebiliyor mu?

Teknik akışın tipik adımları şöyledir:

  1. ERP, CRM veya satış sistemi bir fatura kimliği üretir.
  2. Bu kimlikle bir ödeme talebi oluşturulur.
  3. Müşteri onaylı seçeneklerden birini kullanır.
  4. Sağlayıcı, ödeme durumunu sisteme iletir.
  5. İşletmenin sunucusu bildirimin imzasını doğrular.
  6. Sistem fatura kimliğini, beklenen tutarı ve daha önce işlenmiş bir olay olup olmadığını kontrol eder.
  7. Kayıt tamamlanır; sipariş durumu, işletmenin belirlediği kurala göre güncellenir.

Özellikle aynı bildirimin tekrar gelmesi durumunda sistemin işlemi iki kez yapmaması gerekir. Tekrarlanan bir olay, ikinci bir “ödendi” kaydı, ikinci bir stok ayırma işlemi veya ikinci bir sevkiyat emri yaratmamalıdır.

Ödeme sayfası ile daha derin API entegrasyonu arasındaki farkı değerlendirmek için ödeme bağlantısı ve fatura rehberi yardımcı bir başlangıçtır. Basit bir B2B satışta ödeme sayfası yeterli olabilir; birden çok depo, kısmi sevkiyat veya bayi yapısı olan işletme ise daha ayrıntılı eşleştirme isteyebilir.

İki toptan satış senaryosu

Yedek parça toptancısı

Otomotiv yedek parçası satan bir şirket, müşteriden siparişin yüzde 30’u kadar kapora alır. Stok ayrıldıktan sonra kalan tutar sevkiyat öncesinde tahsil edilir. Müşteri, kapora için doğru referansla ödeme yapar; ancak bakiye ödemesinde beklenen tutardan daha düşük bir miktar gönderir.

Doğru süreçte sistem ikinci faturayı otomatik olarak “tamamlandı” yapmaz. Kayıt istisna kuyruğuna gider. Finans, tutarı ve sözleşmeyi kontrol eder; satış temsilcisi müşteriye eksik tutar için net bir mesaj gönderir. Depo, sadece işletmenin belirlediği onay durumundan sonra sevkiyatı başlatır.

Bu modelde stablecoin tahsilatının faydası, istisnayı yok etmek değildir. Ödeme ve sipariş verisinin aynı referansta toplanmasıyla istisnayı izlenebilir hâle getirmektir.

İhracat için ön ödeme alan üretici

Bir üretici, yabancı alıcı için özel üretim başlatmadan önce ön ödeme alır. Alıcıya fatura numarası, sözleşme referansı ve son ödeme zamanı içeren ayrı bir ödeme talebi gönderilir. Ödeme onaylandığında üretim planlama ekibi, kaynağı belli bir tahsilata dayanarak üretim emrini açar.

Bu işletme için kritik konu, destek ekibinin bir işlem kimliğini görmesi değil; finansın tahsilatı belgeleyebilmesi ve üretimin yanlışlıkla erken başlamamasıdır. Ödeme kaydı, sözleşme, proforma fatura ve müşteri hesabı birbirinden kopmamalıdır. Uluslararası B2B hizmet ve tahsilat akışına dair genel yaklaşım için B2B uluslararası kripto ödemeleri içeriği de incelenebilir.

Mutabakat için gerekli kayıtlar

Her tahsilat kaydında en az şu bilgiler bulunmalıdır: iç fatura numarası, müşteri veya kurum kimliği, beklenen ve alınan tutar, kullanılan varlık/ağ, işlem kimliği, bildirim zamanı, onay durumu ve ilgili sipariş ya da sözleşme. İşletme kendi muhasebe kuralına göre kur veya değerleme bilgisini de eklemelidir.

Bu kayıtların finans ve satış sisteminde aynı referans üzerinden aranabilmesi önemlidir. Aksi hâlde ay sonu kapanışında ekip, blokzincir işlemi, e-posta ve Excel dosyasını birleştirmeye çalışır. Tahsilat sürecinin amacı bu manuel aramayı azaltmaktır; yerel muhasebe sorumluluğunu ortadan kaldırmak değildir.

Cryptoway’in küresel işletmeler ve e-ticaret çözümleri, işletmenin kendi sürecine hangi özellikleri uyarlaması gerektiğini anlamak için incelenebilir. Uygunluk kararı yine işletmenin sözleşmesi, müşterisi ve iç kontrolü üzerinden verilmelidir.

Hangi durumlarda stablecoin tahsilatı uygun olmayabilir?

İşletme, müşteri ile net bir sözleşme ve fatura ilişkisi kuramıyorsa bu yöntem uygun olmayabilir. Aynı şekilde, müşteri kartla ödeme ve kart sistemine özgü itiraz mekanizması bekliyorsa başka bir yöntem daha doğru olabilir. Çok sayıda küçük ve geri ödeme ihtimali yüksek işlemde, istisna politikası belirlenmeden lansman yapmak da risklidir.

Yerel hukuki, vergisel veya muhasebesel değerlendirme tamamlanmamışsa süreç ertelenmelidir. Stablecoin kullanımı, bankacılık ya da düzenleyici kısıtlamaları aşma yöntemi olarak sunulmamalı ve bu amaçla tasarlanmamalıdır. İşletmenin meşru ticari sürecini, belgelerini ve müşteriye karşı açık iletişimini koruması esastır.

Sevkiyat serbest bırakma matrisi

Tahsilat akışında en faydalı iç kontrol, ödeme durumunu teslimat durumundan ayıran basit bir matristir. Örneğin “ödeme talebi oluşturuldu” durumunda satış ekibi müşteriye yalnızca talimat gönderir. “İşlem görüldü” durumunda ekip müşteriye ödeme alındığını fakat kontrolün sürdüğünü bildirir. “Ödeme onaylandı” durumunda finans kaydı kapatır; ancak depo emri sadece ürün, sözleşme ve sevkiyat şartları da sağlanıyorsa açılır.

Bu ayrım özellikle kısmi teslimat yapan firmalarda işe yarar. İlk parti sevk edilmeden önce bakiye tahsil edilmesi gerekiyorsa sistem, kapora kaydını bakiye kaydı yerine kullanmamalıdır. Bir satış yöneticisinin ekranda gördüğü olumlu ödeme mesajı, depoya otomatik olarak “tamamını gönder” talimatı vermemelidir. Müşteriye iletilen her durum mesajı da aynı kurala dayanmalıdır; aksi hâlde satış ve depo birbirini çelişen beklentilere sokar. Bu metinler satış temsilcilerinin kişisel yorumuna bırakılmamalı, onaylı şablon olarak kullanılmalıdır.

Matriste en az dört istisna ayrı tanımlanmalıdır: düşük tutar, yüksek tutar, geç ödeme ve yanlış ağ. Her satır için karar sahibini, müşteriye gönderilecek metni ve muhasebe kaydını belirleyin. Böylece ilk gerçek olayda ekip yeni bir kural üretmek yerine önceden onaylanmış süreci uygular.

Dört haftalık kontrollü pilot

İlk hafta, tek bir ürün grubu ve tek bir satış türü seçin: örneğin belirli yedek parçalar için kapora. İkinci hafta, fatura numarası, ödeme talebi, bildirim doğrulaması ve istisna kuyruğu ile test akışını kurun. Üçüncü hafta, doğru ödeme dışında kısmi ödeme, geç ödeme ve tekrarlanan bildirim senaryolarını deneyin.

Dördüncü hafta, yöntemi sınırlı sayıda uygun müşteriye açın. Gün sonunda satış, finans ve destek ekipleri şu soruları gözden geçirsin: Her ödeme doğru faturaya bağlandı mı? Sevkiyat yalnızca onaylı kayıttan sonra mı başladı? Müşteri yanlış bir adım attığında ekip nasıl yanıt verdi? Finans gerekli bilgileri dışa aktarabildi mi?

Başarılı pilot, sadece bir tahsilat alınması değildir. Başarı; her ödemenin bir siparişe bağlanması, istisnaların kontrollü yönetilmesi ve ekiplerin aynı kaydı görmesidir. Başlangıç seviyesindeki ürün soruları için SSS bölümü ek bağlam sağlayabilir.

Pilot sonrasında işletme, müşteri sorularını ve manuel incelemeleri sınıflandırmalıdır. Aynı sorun iki kez görülüyorsa onu yalnızca destek notuna eklemek yerine ödeme talimatına, satış şablonuna veya sistem kuralına taşımak gerekir. Bu geri bildirim döngüsü, yöntem genişletilmeden önce gerçek operasyon maliyetini görünür kılar. Böylece yönetim kararı, yalnızca tahsilat adedine değil; hata oranına, çözüm süresine ve mutabakat kalitesine dayanır. Bu değerlendirme düzenli olarak satış, finans ve operasyon sorumlularıyla paylaşılmalıdır. Yönetim ayrıca pilotta kullanılan istisna kararlarını kayıt altına almalı; hangi müşterinin hangi nedenle manuel incelemeye girdiğini düzenli olarak gözden geçirmelidir. Bu sayede kapsam genişletilirken aynı belirsizlikler yeniden oluşmaz ve ekiplerin sorumlulukları açık kalır.