Bir müşteri yeni sipariş verir, satış temsilcisi siparişi sisteme girer, depo hazırlar, mal yola çıkar. Fatura kesildikten üç ay sonra tahsilat departmanı cari hesap ekstresine bakar ve müşterinin zaten iki ay önce belirlenen limitin üstünde olduğunu fark eder — üstelik bu sipariş de üstüne eklenmiştir. Kimse kötü niyetli değildir; satış temsilcisi ciro peşindedir, depo siparişi görür ve hazırlar, cari hesap bakiyesi ise ayrı bir ekranda, ayrı bir departmanın sorumluluğundadır. Sipariş anında hiç kimse bu iki bilgiyi yan yana koymamıştır.
Kredi limiti, çoğu işletmede bir Excel notu ya da satış müdürünün ezberinde yaşar. Oysa bu, satışın onaylandığı anda otomatik devreye girmesi gereken bir kontrol noktasıdır — ciroyu engellemek için değil, hangi ciro tahsil edilebilir olduğunu görünür kılmak için.
Kredi limiti neden fatura kesildikten sonra değil, sipariş anında kontrol edilmeli?
Alışılmış akışta risk kontrolü genelde ay sonu mutabakatında, yani zarar çoktan oluştuktan sonra yapılır. O noktada elde tek seçenek kalır: tahsilat departmanının müşteriyi arayıp ödeme istemesi. Sipariş zaten sevk edilmiştir, mal geri alınamaz.
ERP'de kontrol noktası siparişin oluşturulduğu ana taşınır. Sipariş kaydedilirken sistem, müşterinin güncel cari hesap durumunu anlık okur ve yeni siparişin toplamını bu bakiyeye ekler. Limit aşılıyorsa bu bilgi, mal depodan çıkmadan önce satış temsilcisinin ve gerekiyorsa onay verecek kişinin önüne gelir. Fark, "geç mi tahsil ederiz" sorusundan "bu satışı bu koşullarda yapmalı mıyız" sorusuna geçmektir.
Limite hangi tutarlar dahil edilmeli — sadece vadesi gelmiş borç mu?
Burada sık yapılan bir basitleştirme hatası var: kredi limitini yalnızca "vadesi geçmiş, ödenmemiş fatura" tutarıyla karşılaştırmak. Bu ölçü gerçek riski eksik gösterir, çünkü henüz faturalanmamış ama zaten teslim edilmiş ya da onaylanmış siparişler de gelecekteki borçtur.
Gerçek risk resmi dört katmandan oluşur:
| Katman | İçerik |
|---|---|
| Vadesi gelmemiş açık bakiye | Kesilmiş ama vadesi henüz gelmemiş faturalar |
| Vadesi geçmiş bakiye | Ödeme tarihi geçmiş, tahsil edilmemiş faturalar |
| Sevk edilmiş, faturalanmamış tutar | Mal çıkmış, fatura henüz kesilmemiş |
| Onaylanmış açık sipariş | Henüz sevk edilmemiş ama onaylanmış siparişler |
Bir işletme yalnızca ilk iki katmanı izlerse, elinde aslında müşterinin gerçek borcunun bir kısmı görünmez kalır — özellikle sevkiyat ile faturalama arasında birkaç günlük gecikme olan işletmelerde bu fark küçümsenmeyecek boyuta ulaşabilir. ERP'de limit kontrolü bu dört katmanın toplamı üzerinden çalışır; yeni bir sipariş girildiğinde sistem "bu müşterinin şu an sistemde görünen toplam yükümlülüğü nedir" sorusunu, tek bir ekrana bakmadan otomatik cevaplar.
Limit aşıldığında sipariş durur mu, yoksa yalnızca uyarır mı?
Bu ayrım işletmeden işletmeye değişir ve tek doğru cevap yoktur — ama cevabın önceden tanımlı olması gerekir. Üç yaygın davranış vardır:
- Sert engelleme: Limit aşıldığında sipariş kaydedilemez; yalnızca yetkili bir onayla ilerler.
- Yumuşak uyarı: Sipariş kaydedilir ama ekranda görünür bir uyarı çıkar; satış temsilcisi bilgiyle ilerler ya da vazgeçer.
- Koşullu geçiş: Aşım belirli bir eşiğin altındaysa uyarı yeterlidir; eşiğin üstündeyse onay zorunlu hale gelir.
Sert engelleme her müşteri için doğru değildir — uzun süredir düzenli ödeyen, ilişkisi güçlü bir müşteride küçük bir aşım için siparişi tamamen durdurmak ticari ilişkiyi gereksiz yere zorlar. Koşullu geçiş bu yüzden çoğu işletmede daha gerçekçi çalışır: aşım küçükse satış devam eder ve kayıt altına alınır, aşım büyükse iş akışı otomatik olarak bir onay adımına düşer. Önemli olan, bu kararın satış temsilcisinin o anki takdirine değil, önceden tanımlanmış bir kurala bağlı olmasıdır.
Onay yetkisi kimde olmalı — satış mı, finans mı?
Kredi limiti aşımını onaylama yetkisi satış tarafında kalırsa, ciro baskısı risk değerlendirmesini her seferinde geçersiz kılar; finans tarafında kalırsa süreç yavaşlar ve satış ekibi her seferinde ayrı bir onay beklemek zorunda kalır. Sağlıklı kurulum ikisi arasında bir eşik tanımlar:
- Küçük aşımlar (örneğin limitin belirli bir yüzdesine kadar) satış müdürünün onayıyla ilerler.
- Büyük aşımlar finans/muhasebe onayına düşer.
- Belirli bir eşiğin üstündeki aşımlar, teminat mektubu veya peşin ödeme gibi ek bir koşula bağlanmadan onaylanamaz.
ERP'de bu, statik bir kural değil, yetki matrisine bağlı bir iş akışıdır: onay isteyen kişi, tutara göre doğru onaylayıcıya otomatik yönlendirilir. Kimin onayladığı, hangi tarihte onayladığı ve hangi gerekçeyle onayladığı kayıt altına alınır — altı ay sonra "bu satışı kim onayladı" sorusunun cevabı hafızada değil, sistemde durur.
Yeni müşteride limit nereden başlar?
Geçmiş ödeme kaydı olmayan yeni bir müşteri için limit belirlemek, mevcut müşterininkinden farklı bir mantık gerektirir. Burada referans noktası genelde üç kaynaktan biridir: sektördeki benzer ölçekli müşterilerle karşılaştırma, ilk siparişlerde düşük bir başlangıç limitiyle başlayıp ödeme geçmişi oluştukça kademeli artırma, ya da teminat mektubu/çek karşılığı gibi bir güvence talep etme.
Kademeli artırma yaklaşımı özellikle sağlıklı çalışır: yeni müşteriye düşük bir limitle başlanır, ilk birkaç fatura vadesinde sorunsuz ödendikçe limit kademeli yükseltilir. Bu, "güven zamanla kazanılır" ilkesini manuel takip gerektirmeden işletir — ERP'de müşterinin ödeme performansı (vadesinde ödeme oranı, gecikme süresi) izlenip limit revizyonu için bir hatırlatma üretebilir; nihai karar yine de finans tarafında kalır, sistem sadece veriyi zamanında önüne koyar.
Limit tek bir merkezi kural mı, yoksa müşteri/ürün bazında mı değişmeli?
Tek bir genel limit politikası basit görünür ama gerçek risk profiliyle örtüşmeyebilir. İki müşteri aynı ciroyu yapsa bile biri düzenli, öngörülebilir ödeme yaparken diğeri sürekli vade sonuna yaklaşır — ikisine aynı katılık uygulamak, iyi müşteriyi gereksiz yere kısıtlar ya da riskli müşteriye gereğinden fazla alan bırakır.
ERP'de limit müşteri bazında tanımlanır ve ayrıca kur, ödeme vadesi, ödeme geçmişi gibi değişkenlerle ilişkilendirilebilir. Grup şirketi ya da bayi ağı üzerinden çalışan işletmelerde bir üst kırılım daha eklenir: tek bir grup için konsolide bir üst limit tanımlanıp, alt bayilerin toplam kullanımı bu üst limitle sınırlandırılabilir — böylece aynı grubun farklı şubelerden yaptığı siparişler tek tek değil, toplam risk üzerinden değerlendirilir.
Birasyo'da kredi limiti kontrolü nasıl kurulur?
Birasyo ERP'de kredi limiti, satış siparişinin ayrılmaz bir parçasıdır, ayrı bir kontrol adımı değil:
- Sipariş kaydedilirken sistem müşterinin güncel cari hesap bakiyesini, vadesi geçmiş tutarları, sevk edilmiş-faturalanmamış tutarları ve açık siparişleri tek bir toplamda birleştirip tanımlı limitle karşılaştırır.
- Aşım tespit edildiğinde, tanımlı eşiğe göre sipariş ya uyarıyla ilerler ya da yetki matrisinde tanımlı onaylayıcıya otomatik yönlendirilir; onay geçmişi kalıcı olarak kaydedilir.
- Limit, müşteri bazında Satış modülünde tanımlanır ve cari hesap ekranından beslenen güncel bakiyeyle her sipariş anında yeniden hesaplanır — ayrı bir rapor çalıştırmaya gerek kalmaz.
- Yeni müşteri için başlangıç limiti düşük tanımlanabilir; ödeme geçmişi biriktikçe limit revizyonu için hatırlatma üretilir, nihai onay finans tarafında kalır.
Bu kurgu, satış hızını düşürmeden riski satış anında görünür kılar — sorunu ay sonunda değil, sipariş girilirken yakalar.
Özet
Kredi limiti kontrolü, ay sonu mutabakatında fark edilecek bir sorun değil, sipariş anında karar verilecek bir kontrol noktasıdır. Doğru bir kurulumda limit yalnızca vadesi geçmiş borcu değil, açık bakiye, sevk edilmiş-faturalanmamış tutar ve onaylanmış siparişleri birlikte kapsar; aşım anında sipariş otomatik durmaz ama tanımlı bir eşiğe göre ya uyarır ya da doğru onaylayıcıya yönlendirilir. Onay yetkisinin satış ile finans arasında net paylaşılması, ciro baskısının risk değerlendirmesini geçersiz kılmasını engeller. Bu adımlar tek bir akışa bağlandığında kredi riski, kimin sorumluluğunda olduğu belirsiz bir gri alan olmaktan çıkar.
Kredi limiti sürecinizin hangi noktada koptuğunu birlikte görmek isterseniz demo talebi üzerinden bir görüşme planlayabiliriz.
İlgili yazılar:
Bu yazıyı LinkedIn'de paylaşın
Başlık, özet ve hashtagler panoya kopyalanır, LinkedIn paylaş penceresi açılır — yapıştırın (Cmd/Ctrl+V) ve gönderin.
