B2B siparişleri için kredi limiti kontrolü ve müşteri bazlı ödeme koşulları

Kredi limiti kontrolünün çözdüğü sorun (düz dille)

B2B siparişleri kağıt üzerinde sağlıklı görünebilir ama yine de nakit sıkışmasına yol açabilir. Kart ödemelerinin aksine birçok ticari müşteri sonra ödeme yapar. Faturalar yığılmaya devam ederken sevkiyata devam ederseniz, tek bir yavaş ödeyen sessizce işletme sermayenizin büyük bir bölümünü bloke edebilir.

Kredi limiti kontrolü, bir sipariş tam olarak kabul edilmeden önce yapılan basit bir güvenlik kontrolüdür. Müşterinin zaten ne kadar borcu olduğu (ve bu siparişle ne kadar daha borçlanacağı) belirlenmiş kredi limiti ile karşılaştırılır. Yeni sipariş limiti aşacaksa sistem siparişi kalıcı olarak reddetmez; siparişi inceleme için beklemeye alır.

Bekletme genellikle siparişin kaydedildiği, ancak bazı temel adımların birisi onay verene kadar engellendiği anlamına gelir. Alıcı ile ayrıntıları doğrulayabilir ve politika gerektiriyorsa stok ayırtabilirsiniz. Tipik olarak yapmadığınız şey ise bekletme çözülene kadar sevkiyat yapmak, fatura kesmek veya stoğu kalıcı olarak ayırmaktır.

Ödeme koşulları riski değiştirir çünkü paranızın ne kadar süreyle bağlı kalacağını etkiler. Peşin ödeme düşük risktir çünkü para önce gelir. Net 30, harcamalar limit içinde kaldığı ve faturalar zamanında ödendiği sürece uygun olabilir. Net 60 (veya özel koşullar) daha uzun süre için maruziyeti artırır.

Bir kontrol ayrıca ekipler arasındaki kafa karışıklığını azaltır; çünkü "bunu sevk edebilir miyiz?" sorusunu satış, finans ve operasyonlar için görünür, tutarlı bir duruma dönüştürür.

Müşteri başına hangi verileri saklamalısınız (limitler, koşullar, maruziyet)

Kontrol sadece müşteri kaydında arka uç kuralınızın güvenebileceği birkaç alan varsa çalışır. Listeyi kısa tutun ve her değeri kolayca açıklanabilir yapın.

Kredi limiti ile başlayın: limit tutarı ve tanımlı olduğu para birimi. Birden fazla para biriminde satış yapıyorsanız bir kural seçin ve ona sadık kalın. Karşılaştırmadan önce her şeyi bir temel para birimine çevirin veya limitleri para birimine göre saklayın.

Sonra ödeme koşullarını serbest metin yerine yapılandırılmış veri olarak saklayın. Açık bir tür kullanın (Prepay, COD, Net 15, Net 30, Net 60) ve ilgiliyse net gün sayısını saklayın. Böylece sipariş mantığınız tahminde bulunmadan dallanabilir.

Pratik bir müşteri seti şu alanları içerir:

• Kredi limiti tutarı ve para birimi
• Ödeme koşulu türü ve net gün sayısı (varsa)
• Geçici bir yetki miktarı (opsiyonel) ve bitiş zamanı
• Yetki notu (neden verildiği ve kim tarafından)
• Manuel bekletme anahtarı (bir "durdur" düğmesi)

"Maruziyeti" işletmenizin riski nasıl taşıdığıyla uyumlu şekilde tanımlayın. Birçok ekip ödenmemiş faturaları ve henüz ödenmemiş açık siparişleri dahil eder; bazen fatura sevkiyattan sonra kesiliyorsa bekleyen sevkiyatları da dahil ederler.

Son olarak, bekletmelerin görünür ve işlem yapılabilir olması için küçük bir sipariş durumu seti tutun. Örneğin: Onaylandı, Beklemede, Serbest Bırakıldı, İptal Edildi.

Limitler, koşullar ve sipariş bekletmeleri için veri modeli

Veri modeliniz üç soruyu kolay cevaplayacak şekilde olmalı: kim satın alıyor, hangi koşullarda ve zaten ne kadar borcu var.

Karar girdilerini taşıyan bir Müşteri kaydıyla başlayın: kredi limiti, varsayılan ödeme koşulları ve bir bekletme politikası (örneğin, limitin aşılması halinde otomatik bekletme, izin ver ama işaretle veya ödeme sırasında engelle).

Siparişler hem tetikleyiciyi hem sonucu yakalamalıdır. Ödeme yöntemi, sipariş toplamı ve "Beklemede" durumunu temsil edebilecek bir durum alanı tutun. Bir bekletme nedeni ekleyin ki insanlar "kredi limiti aşıldı" ile diğer sorunları (adres doğrulama gibi) ayırt edebilsin.

Minimal bir şema genellikle şunları içerir:

• Customers: credit_limit, payment_terms_code, hold_policy, credit_status
• Orders: total_amount, payment_method, status, hold_reason, held_at
• Invoices / AR: invoice_total, open_balance, due_date, status (open/paid/void)
• Credit overrides: customer_id, override_amount_or_limit, expires_at, approved_by
• Audit log: entity_type, entity_id, changed_fields, changed_by, changed_at, note

Maruziyeti güvenilir şekilde hesaplamak için alacak verilerine (faturalar veya harici bir senkronizasyon) ihtiyacınız var ki ödenmemiş bakiyeler siparişlerden tahmin edilmesin. Henüz faturalama yoksa, müşteri üzerinde bir "açık bakiye" anlık görüntüsü saklayın ve gönderilen ödemelerden güncelleyin.

Yetkileri ayrı bir tabloda tutun. Bu, ana kredi limitine yapılan karışık düzenlemeleri önler ve onay izini sağlar.

Kredi maruziyeti ve kullanılabilir kredi nasıl hesaplanır

Matematiğin üzerinde anlaşılması ve yazılı hale getirilmesi, ardından uygulama ve finansal raporlar boyunca tutarlı kullanılması gerekir.

Yaygın bir temel:

Kredi maruziyeti = ödenmemiş faturalar + açık sipariş değeri

Sonra:

Kullanılabilir kredi = kredi limiti - kredi maruziyeti

Uygulamadan önce "değer"in ne anlama geldiğini tanımlayın. Birçok ekip ürün toplamlarını indirimler düşüldükten sonra kullanır, sonra vergi ve kargoyu dahil edip etmeme konusunda açık bir karar verir. Vergi ve kargoyu dahil ederseniz bekletmeler daha erken tetiklenir. Hariç tutarsanız, fatura kesinleşince limitin aşılma riski olur.

Birkaç ayarlama sürprizleri önler:

• Kısmi ödemeler, nakit fiilen alınana kadar ödenmemiş faturaları sadece o zaman azaltır ("başlatılan" bir ödeme değil).
• Kredi notları ve iadeler sadece verildiğinde ve kullanıma onaylandığında maruziyeti azaltır.
• İptal edilen siparişler açık sipariş değerinden hemen düşmelidir.
• İadeler genellikle kredi notu onaylandıktan sonra maruziyeti azaltır, iade talebi yapıldığında değil.

Zamanlama formül kadar önemlidir. Sayıların tahmin edilebilir olması için net güncelleme noktaları seçin:

• Sipariş oluşturma veya sipariş onayı (birini seçin ve tutarlı olun)
• Fatura düzenleme (açık siparişten ödenmemiş faturaya değer taşınır)
• Ödeme kaydı (maruziyeti serbest bırakır)

Birden fazla para biriminde satıyorsanız maruziyeti müşterinin kredi para birimine tutarlı bir kur ile çevirin (örneğin, fatura tarihindeki günlük kur). Ana hesaplar veya bağlı kuruluşlar destekliyorsanız limitlerin tüzel kişiye göre mi yoksa grupça mı paylaşıldığını kararlaştırın ve bunu müşteri kaydında görünür yapın.

Adım adım: siparişleri bekleten arka uç kuralını oluşturma

Kontrol en iyi, her sipariş oluşturulduğunda veya değiştiğinde otomatik çalıştığında işler.

1. Alıcı tek tıklamayla gönderse bile siparişi önce taslak olarak kaydedin. Müşteri kimliğini, sipariş toplamını, para birimini ve ödeme koşullarının bir anlık görüntüsünü yakalayın ki sonraki müşteri profil düzenlemeleri geçmişi yeniden yazmasın.

2. Müşterinin geçerli maruziyetini alın (tanımınıza göre). Yeni sipariş toplamını ekleyerek projekte edilen maruziyeti hesaplayın.

3. Basit bir karar uygulayın:

• Eğer projekte edilen maruziyet kredi limiti içindeyse, siparişi Onaylandı olarak işaretleyin.
• Eğer projekte edilen maruziyet limiti aşıyorsa, siparişi Beklemede olarak ayarlayın.

4. Siparişi bekletirken, kararın daha sonra kolayca açıklanmasını sağlayacak ayrıntıları kaydedin:

• Bekletme nedeni (ör. "Kredi limiti $2,450 aşıldı")
• Bir sonraki işlem sahibi (ör. "AR ekibi" veya belirli bir yönetici)
• O anki limit, maruziyet bileşenleri, kim tetikledi, zaman damgası gibi girdileri içeren bir denetim kaydı

5. Maruziyeti yalnızca oluşturma anında değil, sayıları değiştiren olaylarda da yeniden kontrol edin. Yaygın tetikleyiciler: toplamı değiştiren düzenlemeler, sevkiyat (politikaya bağlı olarak sevkiyat taahhüt sayılabilir), faturalama ve ödeme kaydı.

Onaylar ve bildirimler: bekletilmiş siparişlerin takılı kalmaması için

Bir bekletme ancak hızlı ve izlenebilir bir karara götürdüğünde yararlıdır.

Kimlerin bekletmeyi kaldırabileceğini tanımlayın. Birçok ekip kredi kararları için finansı, acil durumlar için satış yöneticisini yedek olarak kullanır. Rolleri ve izinleri açıkça belirtin ve her zaman kimin onayladığını (veya reddettiğini) ve nedenini kaydedin.

Onay ekranında ne gösterilmeli

Ekranı kısa tutun ama onaylayanın ihtiyaç duyacağı sayıları ekleyin:

• Kredi limiti, güncel maruziyet, kullanılabilir kredi
• Sipariş toplamı ve limitin ne kadar aşıldığı
• Kayıttaki ödeme koşulları ve talep edilen koşullar (farklıysa)
• Kısa bir müşteri durum notu seti (ör. "yeni hesap" veya "daha önce gecikme yaşandı")
• Zorunlu bir yorum alanı

Karardan sonra bir onay kaydı yazın (sipariş ID, karar, onaylayan, zaman damgası, yorum). Bu denetim izi olur ve gecikmeleri açıklamada yardımcı olur.

Bildirimler ve zaman sınırları

Sipariş beklemeye alındığında doğru kişilere anlık bildirim gönderin; ekiplerin gerçekten okuduğu kanalları kullanın (e-posta, SMS veya Telegram gibi). Hatırlatmalar ve yükseltmeler ekleyin ki bekletmeler sessiz kalmasın. Pratik bir model: 2 saatte hatırlatma, 24 saatte yükseltme ve kimse incelemezse 72 saatte otomatik iptal.

Tam serbest bırakma çok riskliyse koşullu serbest bırakmalara izin verin (kısmi sevkiyat, depozito gereksinimi, daha kısa ödeme koşulu) ve koşulu kaydedin ki gerçekleştirme ve faturalama aynı plana uysun.

Operasyonel akış: bir sipariş beklemeye alındıktan sonra ne olur

Bekletilen bir siparişi normal bir sipariş gibi ele alın ama tek fark: bekletme çözülene kadar ilerleyemez.

Satış, operasyon ve finans aynı bekletme sinyalini görmelidir. "Kredi beklemede" gibi bir durum ve bir neden alanı ekleyin (ör. "Maruziyet limitin $1,240 üzerinde"). Kısa bir dahili not ekleyin ki insanlar tahmin yürütmek zorunda kalmasın.

Depo kuralları katı olmalıdır: beklemedeki siparişler seçilmez, paketlenmez veya tahsis edilmez. Stok ayırıyorsanız, yalnızca serbest bırakmadan sonra ayırın veya bekletme siparişinin ödenmiş siparişlerin önünü kesmemesi için kısa bir rezervasyon penceresi kullanın.

Müşteri iletişimi için mesajı nötr ve pratik tutun, bir sonraki adımı net gösterin. Örneğin:

• "Siparişiniz rutin bir hesap incelemesi için geçici olarak durduruldu. Ödeme zamanlamasını onaylamak için yanıtlayın veya kısmi sevkiyat talep edin."
• "Ödeme alındığında veya kredi limiti ayarlandığında sevkiyat yapabiliriz. Hangi seçenek uygun?"
• "Siparişi bölerek kullanılabilir kredi dahilinde olan ürünleri gönderebiliriz."

Ödeme geldiğinde otomatik serbest bırakma veya manuel serbest bırakma arasında seçim yapın. Ödemelerin faturalarla güvenilir şekilde eşleştiği ortamlarda otomatik serbest bırakma iyi çalışır. Ödemeler kısmi veya belirsizse manuel serbest bırakma daha güvenlidir. Ortak bir uzlaşma: yalnızca ödeme gecikmiş bakiyeyi tamamen kapattığında otomatik serbest bırakma; aksi halde finans incelemesine gönderin.

Kapıyı sağlıklı tutmak için bazı metrikleri takip edin: bekletilen sipariş sayısı, %24 içinde serbest bırakılanların oranı, ortalama serbest bırakma süresi ve bekletme nedenlerinin başlıcaları.

Örnek senaryo: eşiği aşan bir toptan sipariş

Bir toptan müşteri olan BrightSide Supplies, Net 30 ödeme koşuluna ve 50.000 kredi limitine sahip.

Ödenmemiş faturaları toplam 38.000. Yeni bir sipariş için 15.000 sipariş veriyorlar.

Projeksiyon: 38.000 + 15.000 = 53.000. 53.000, 50.000 limitinin üzerinde olduğundan sipariş beklemeye alınır ve inceleme için finansa yönlendirilir. Satış yine siparişi görebilir, ancak risk azaltılana kadar paketleme, sevkiyat veya faturalama yapılamaz.

Finansın birkaç seçeneği vardır: azaltılmış exposure için depozito talep etmek, mevcut kullanılabilir krediye sığacak şekilde siparişi küçültmek veya bir bitiş tarihi ve gerekçe notu olan geçici bir yetki onaylamak.

Açmadan önce hızlı kontrol listesi

Kapatmadan önce üretime almadan kısa bir test yapın. Birkaç saatlik test, sonradan günler sürecek temizlik işini önleyebilir.

5–10 müşteriden oluşan küçük, farklı bir test setiyle başlayın: düşük limitli Net 30, yüksek limitli, peşin ödeme yapan, birden çok açık faturası olan ve ödeme sonrası sıklıkla sipariş düzenleyen bir hesap gibi.

İki şeyi doğrulayın:

• Maruziyet matematiği muhasebenin beklediği ile uyuşuyor mu (neyi saydığınız ve neyi saymadığınız dahil).
• Bekletme kuralı doğru zamanlarda çalışıyor mu: sipariş oluşturma ve maruziyeti artıran düzenlemeler (adet değişikliği, fiyat değişikliği, kargo ekleme, indirim kaldırma) sırasında.

Bir bekletilen siparişi uçtan uca test ederek bekletme nedeninin net olduğunu, sevkiyat ve faturalamanın tam olarak planlandığı gibi davrandığını, bildirimlerin doğru kişilere gittiğini ve bir ödeme tersinin yeniden bekletmeye (veya işaretlemeye) neden olabileceğini doğrulayın.

Yaygın hatalar ve nasıl kaçınılır

Çoğu sorun teknik değildir. Yanlış sayıyı kontrol eden kural veya insanların sistemi aşma yollarını öğrenmesi sorun yaratır.

Yaygın başarısızlık noktaları:

• Maruziyeti açık ve taahhüt edilmiş tutarlar yerine siparişin brüt tutarı olarak ele almak.
• Henüz sevk edilmemiş onaylanmış siparişleri göz ardı etmek; müşterilerin faturalar oluşmadan aynı gün birkaç büyük sipariş vermesine izin vermek.
• Onaylandıktan sonra para tutarını değiştiren düzenlemelere kredi kontrolünü yeniden çalıştırmamak.
• Onaylar için denetim izi olmadan yetkilendirmelere izin vermek.
• Çok fazla istisna ekleyip kapının isteğe bağlı hale gelmesi.

Önlemeyi basit tutun: maruziyeti bir cümleyle tanımlayın, para tutarını değiştiren her düzenlemede gate'i yeniden çalıştırın, yetkiler için bir gerekçe ve onaylayıcı isteyin ve istisna türlerini kısa tutun.

Sonraki adımlar: kapıyı sipariş uygulamanıza uygulayın ve yineleyin

Gerçek riski önleyen en küçük sürümle başlayın: "Bu sipariş sonrası maruziyet müşterinin limitini aşarsa siparişi Beklemede olarak ayarla." Bir hafta çalıştırın, sonra yalnızca açıkça adlandırılabilen istisnaları ekleyin (ör. finans tarafından onaylanan geçici yetkiler).

Uygulamayı el ile kodlamadan kuruyorsanız, AppMaster (appmaster.io) pratik bir seçenek olabilir: müşterileri, siparişleri, faturaları ve yetkilendirmeleri görsel olarak modelleyebilir, ardından oluşturma, düzenleme, faturalama ve ödemelerde maruziyeti yeniden hesaplayan bir arka uç iş süreci uygulayabilirsiniz.

İlk sürümü sıkıcı ve öngörülebilir tutun. Finans ve operasyonların her gün gördüklerine göre geliştirin.