B2B'de Cari Hesap, Vade, Limit ve Ödeme Koşulları Nasıl Yönetilir?

B2B'de Ödeme Yöntemi, Ticari Koşulun Yalnız Bir Parçasıdır

B2C checkout çoğu zaman müşterinin ödeme yöntemini seçip anında tahsilat yapmasıyla tamamlanır. B2B'de ise siparişin kabul edilip edilmeyeceğini cari hesap, açık bakiye, vade, kredi/risk limiti, gecikmiş borç ve müşteri segmenti gibi ticari kurallar etkileyebilir.

Bu nedenle finansal kontrol, yalnız ödeme ekranına eklenen birkaç seçenekten ibaret değildir. Sipariş motoru ile ERP/muhasebe verisinin hangi noktada ve hangi kuralla birlikte çalışacağını tanımlamak gerekir.

1. Cari Hesap Nedir?

Cari hesap, işletmenin müşteriyle olan ticari alacak, borç ve hareketlerini izlediği hesaptır. B2B portalında bu hesabın tamamı tutulmak zorunda değildir; çoğu yapıda ERP veya muhasebe sistemi finansal ana kaynaktır.

• Cari kod.
• Açık bakiye.
• Vadesi geçmiş tutar.
• Kredi/risk limiti.
• Kullanılabilir limit.
• Ödeme koşulu.
• Para birimi.
• Bloke durumu.

2. Portal ile Finans Sisteminin Sınırını Belirleyin

Portal müşteriye finansal görünüm ve sipariş deneyimi sunabilir; ancak hangi finansal verinin ERP/muhasebeden geldiği açıkça belirlenmelidir.

3. Ödeme Koşulu

• Peşin ödeme.
• Kartla ödeme.
• Havale/EFT.
• Açık hesap/cari.
• Belirli gün vadeli ödeme.
• Sipariş bazlı özel koşul.
• Müşteri segmentine özel koşul.

Müşterinin kullanabileceği ödeme yöntemleri hesap seviyesinde tanımlanabilir.

4. Vade Mantığı

Vade yalnız '30 gün' metni değildir. Başlangıç tarihi ve hesaplama kuralı tanımlanmalıdır.

• Sipariş tarihinden itibaren.
• Fatura tarihinden itibaren.
• Sevkiyat tarihinden itibaren.
• Sözleşmeye özgü hesaplama.

Gerçek finansal uygulama işletmenin muhasebe politikası ve geçerli düzenlemelerle uyumlu olmalıdır.

5. Kredi/Risk Limiti

Limit, müşterinin açık hesapla taşıyabileceği riskin sınırlandırılmasında kullanılabilir.

6. Kullanılabilir Limit Formülü

Basitleştirilmiş eğitim modeli: Kullanılabilir Limit = Tanımlı Limit − Hesaplanan Mevcut Risk.

Bu formülün bileşenleri işletmeye göre değişebilir; portal kendi bağımsız finans formülünü üretmemelidir.

7. Açık Siparişler Limiti Etkiler mi?

Henüz faturalanmamış fakat onaylanmış siparişler risk hesabına dahil edilecekse rezervasyon mantığı gerekir.

8. Eşzamanlı Limit Kontrolü

İki kullanıcı aynı şirket hesabından aynı anda sipariş veriyorsa yalnız ekranda gösterilen limit yeterli değildir. Kesinleştirme sırasında atomik veya güvenilir rezervasyon/kontrol mekanizması gerekir.

9. Limit Aşımında Ne Olur?

• Siparişi bloke et.
• Finans/satış onayına gönder.
• Aşan kısmı peşin ödeme iste.
• Farklı ödeme yöntemine yönlendir.
• Teklif/satış temsilcisine aktar.

Davranış müşteri segmenti ve şirket politikasına göre tanımlanmalıdır.

10. Gecikmiş Borç Kuralı

Müşterinin kullanılabilir limiti olsa bile vadesi geçmiş borç nedeniyle yeni sipariş kısıtlanabilir.

• Tam blokaj.
• Belirli gecikme gününden sonra blokaj.
• Yalnız vadeli siparişi kapatma.
• Finans onayı gerektirme.

Portal, ERP'deki finansal durumla çelişen bağımsız bir karar vermemelidir.

11. Müşteri Blokajı

Finansal, operasyonel veya sözleşmesel nedenle hesap siparişe kapatılabilir.

Kullanıcıya yalnız 'hata' göstermek yerine uygun açıklama ve iletişim yolu sunulmalıdır; hassas iç risk detayları gereksiz biçimde ifşa edilmemelidir.

12. Peşin ve Vadeli Siparişi Ayırın

Aynı müşteri bazı siparişlerde açık hesap, bazı siparişlerde kart veya havale kullanabilir.

13. Havale/EFT Akışı

1. Sipariş taslak/bekleyen ödeme durumunda oluşur.
2. Müşteriye ödeme referansı gösterilir.
3. Tahsilat finans sistemiyle eşleştirilir.
4. Doğrulama sonrası sipariş kesinleşir veya operasyon akışı ilerler.

Yalnız müşterinin 'ödedim' beyanıyla tahsilat kesinleşmiş sayılmamalıdır.

14. Kartla Ödeme

Kartla ödeme kullanılan B2B akışında başarılı tarayıcı dönüşü tek başına yeterli değildir. Sağlayıcı işlemi güvenilir sunucu tarafı mekanizmayla doğrulanmalıdır.

• Payment intent/işlem referansı.
• Sunucu doğrulaması/callback.
• Idempotency.
• Başarısız/timeout durumu.
• Refund/iptal ilişkisi.

15. Kısmi Ödeme veya Karma Model

Bazı işletmeler siparişin bir kısmını peşin, kalanını vadeli kabul edebilir. Böyle bir model kullanılacaksa finansal hareketler ayrı ve izlenebilir olmalıdır.

Gereksiz karmaşıklık yaratmamak için gerçek ticari ihtiyaç yoksa ilk sürümde uygulanmaması düşünülebilir.

16. Ön Ödeme / Depozito

Proje veya özel üretim siparişlerinde belirli tutar/oran ön ödeme istenebilir.

• Toplam sipariş.
• Depozito oranı/tutarı.
• Tahsil edilen.
• Kalan.
• Son ödeme koşulu.
• Sipariş statüsüne etkisi.

17. Finansal Snapshot

Sipariş kesinleştiğinde o anda uygulanan ticari koşullar saklanmalıdır.

• Ödeme koşulu.
• Vade.
• Kullanılan limit.
• Para birimi.
• Sipariş tutarı.
• Tahsilat yöntemi.
• Onay/istisna referansı.

Daha sonra müşterinin vadesi değiştiğinde geçmiş siparişin koşulları değişmemelidir.

18. Sipariş İptali ve Limit Serbest Bırakma

Sipariş risk rezervasyonu oluşturduysa iptal edilen veya reddedilen siparişin limiti doğru zamanda serbest bırakılmalıdır.

Aksi halde müşteri gerçekte kullanılabilir limiti olduğu halde yeni sipariş veremeyebilir.

19. Kısmi Sevkiyat ve Risk

Kısmi sevkiyat/faturalama kullanılan işletmelerde sipariş rezervasyonu ile gerçekleşen finansal risk arasındaki geçiş modeli tanımlanmalıdır.

Bu mantık ERP/muhasebe sisteminin risk hesabıyla uyumlu olmalıdır.

20. İade ve Finansal Etki

İade; sipariş, tahsilat, cari hesap ve varsa limit/risk üzerinde farklı zamanlarda etki yaratabilir.

Portal yalnız görsel sipariş durumunu değiştirmek yerine finansal kaynak sistemden gelen sonucu doğru yansıtmalıdır.

21. Cari Ekstre Görünümü

Müşteriye cari hareket gösterilecekse veri kaynağı, güncellik ve kapsam açık olmalıdır.

• Belge tarihi.
• Belge tipi.
• Borç/alacak.
• Bakiye.
• Vade.
• Belge referansı.
• Ödeme durumu.

Müşterinin yalnız kendi şirket ve yetkili şube kapsamındaki finansal veriye erişmesi gerekir.

22. Finans Kullanıcısı Yetkisi

Cari bakiye, ekstre veya ödeme işlemleri satın alma kullanıcılarının tamamına açık olmak zorunda değildir. Finans rolü ayrı tutulabilir.

23. Limit Değişikliği

Kredi/risk limiti kritik ticari veridir. Portalda değiştirilebiliyorsa güçlü yetki, audit ve gerektiğinde ikinci onay gerekir. Çoğu yapıda kaynak ERP/finans sistemidir.

24. ERP Kesintisinde Ne Olur?

Sipariş anında limit doğrulaması ERP'ye bağlıysa servis kesintisi davranışı önceden belirlenmelidir.

• Vadeli siparişi geçici durdur.
• Peşin ödeme seçeneği sun.
• Son güvenilir veriyi yalnız görüntüle, kesinleştirmeyi beklet.
• Manuel finans onay kuyruğu oluştur.

25. Finansal Hata Kuyruğu

• Limit servisi hatası.
• Cari eşleşme yok.
• Tahsilat eşleşmedi.
• Sipariş ERP'ye aktarılamadı.
• İptalde limit serbest kalmadı.
• Bakiye senkronizasyon farkı.

Her istisnanın sahibi, SLA'sı ve tekrar deneme/manual çözüm yolu olmalıdır.

26. Finansal KPI'lar

• Vadeli sipariş oranı.
• Limit nedeniyle bekleyen sipariş.
• Finans onay süresi.
• Tahsilat eşleşme süresi.
• ERP finans senkronizasyon hatası.
• Manuel finans müdahalesi.
• Ödeme başarısızlık oranı.

27. Kabul Testleri

1. Standart vadeli müşteri doğru ödeme koşulunu görüyor.
2. Limit içindeki sipariş geçiyor.
3. Limit aşan sipariş politika gereği bloke/onaya gidiyor.
4. İki eşzamanlı sipariş aynı limiti iki kez kullanamıyor.
5. Gecikmiş borç kuralı uygulanıyor.
6. Peşin ödeme limiti uygun biçimde etkiliyor.
7. İptal edilen sipariş rezervasyonu serbest bırakıyor.
8. ERP kesintisi tanımlı fallback davranışını çalıştırıyor.
9. Finans kullanıcısı ekstreyi görüyor; yetkisiz kullanıcı göremiyor.
10. Geçmiş sipariş, müşteri vadesi değişince değişmiyor.

Uygulama: Cari, Vade ve Limit Kural Kitabı

1. Finansal ana kaynak sistemi belirleyin.
2. Müşteri ödeme koşullarını listeleyin.
3. Vade başlangıç kurallarını yazın.
4. Risk limitinin bileşenlerini finans ekibiyle tanımlayın.
5. Açık sipariş rezervasyon kuralını belirleyin.
6. Limit aşımı davranışını yazın.
7. Gecikmiş borç/blokaj politikasını tanımlayın.
8. Peşin, havale ve kart akışlarını ayırın.
9. İptal/iade sonrası limit davranışını yazın.
10. ERP kesinti senaryosunu belirleyin.
11. Finansal snapshot alanlarını seçin.
12. 10 kabul testini sisteminize uyarlayın.

Müşterinin siparişi hangi finansal koşullarla verebileceğini kurduk. Şimdi sipariş öncesi teklif, şirket içi onay, sipariş kesinleştirme ve tekrar sipariş süreçlerini tasarlayacağız.