Çoğu işletme sahibi tedarikçi bakiyesini bir muhasebe detayı sanır. Ayda bir bakılan, gerektiğinde yüklenen, arada unutulan bir sayı. Oysa dijital ürün satışında bakiye muhasebe değil stok demektir. Tedarikçideki bakiyen sıfıra yaklaştığı anda, kataloğunda "stokta" yazan yüzlerce ürün fiilen satılamaz hale gelir ve bunu ilk fark eden sen değil, ödemeyi yapmış müşterin olur.
İşin sinsi tarafı şu: bakiye bitişi gürültülü bir arıza değildir. Site açık, panel çalışıyor, ödeme geçiyor, sadece teslimat olmuyor. Bu yüzden bakiye takibi bir dijital ürün satış yazılımı içinde raporlama değil, operasyonel alarm katmanı olarak tasarlanmalıdır. Bu yazıda bakiyenin nasıl izlendiğini, eşiğin nasıl hesaplandığını, rezerve bakiyenin ne işe yaradığını ve mutabakatın neden haftalık değil günlük yapılması gerektiğini konuşacağız.
Bakiye neden "para" değil "stok" kalemi olarak okunmalı?
Fiziksel üründe stok sayılabilir bir şeydir; rafta on kutu vardır, dokuzu satılır, biri kalır. Dijital üründe rafın kendisi tedarikçideki bakiyendir. 50.000 TL bakiyen varsa ve ortalama alış maliyetin 90 TL ise, elinde yaklaşık 555 satışlık stok var demektir. Bu sayıyı bilmiyorsan stok yönetimi yapmıyorsun, sadece tahmin yürütüyorsun.
Bu bakış açısı değişikliği raporlamayı da değiştirir. "Bakiye: 50.000 TL" cümlesi neredeyse hiçbir şey söylemez. Anlamlı olan cümle şudur: "Mevcut satış hızıyla bu bakiye 31 saat sonra biter." İyi bir e-pin satış yazılımı bakiyeyi tutarla değil kalan süreyle gösterir; çünkü karar verdiren metrik süredir, tutar değil.
Eşik uyarısı tek seviye olduğunda ne olur?
Tek eşik kuran herkes aynı yere gelir: uyarı geldiğinde yükleme yapacak zaman kalmamıştır. Çünkü tedarikçiye para göndermek anlık bir işlem değil; havale saati, onay süresi, hafta sonu, bayi temsilcisinin mesai saati gibi gerçek dünya kısıtları var. Bu yüzden eşik üç seviyeli kurulur.
Birinci seviye bilgi: kalan süre 72 saatin altına indi, planlama yap. İkinci seviye uyarı: 24 saatin altına indi, transferi başlat. Üçüncü seviye kritik: 6 saatin altına indi, o tedarikçiyi yönlendirme sırasında geriye al ve yüksek adetli siparişleri alternatif tedarikçiye kaydır. Üç seviyeyi ayrı kanallara bağlamak da önemlidir: bilgi e-postaya, uyarı panele, kritik doğrudan telefona.
| Seviye | Tetikleyici | Sistem davranışı | Bildirim kanalı |
|---|---|---|---|
| Bilgi | Kalan süre < 72 saat | Panelde sarı işaret | E-posta özeti |
| Uyarı | Kalan süre < 24 saat | Yönlendirme skorunu düşür | Panel bildirimi |
| Kritik | Kalan süre < 6 saat | Yüksek tutarlı siparişleri kaydır | Telefon / anlık mesaj |
| Kilit | Bakiye < tek sipariş maliyeti | Tedarikçiyi aday listesinden çıkar | Tüm kanallar |
Rezerve bakiye ne demek ve neden hesabı kurtarır?
Bir sipariş oluştuğu anda ile tedarikçiye istek gittiği an arasında saniyeler, bazen dakikalar vardır. Yoğun saatte aynı anda kırk sipariş varsa, hepsi "bakiye yeterli" kontrolünü geçer ama toplamları bakiyeyi aşar. Sonuç: ilk on beşi teslim edilir, kalanı hata alır. Klasik bir yarış durumu (race condition).
Çözüm rezerve bakiyedir. Sipariş sıraya girdiği anda tahmini alış maliyeti kadar tutar bloke edilir; teslimat tamamlanınca gerçek tutar düşülür, blokaj çözülür. Hata olursa blokaj iade edilir. Böylece "kullanılabilir bakiye" her zaman gerçek rakamı gösterir. Bir epin yazılım altyapısında bu blokaj mantığı yoksa, yoğun kampanya saatleri kaçınılmaz olarak kısmi teslimatla geçer.
Bakiye kaynaklı kayıpların dağılımı
- Geç fark edilen bakiye bitişi 50%
- Rezerve olmadan yarış durumu 25%
- Kur farkı kaynaklı sapma 15%
- Mutabakat hatası / eksik kayıt 10%
Mutabakat neden haftalık değil günlük yapılmalı?
Senin panelindeki bakiye, tedarikçinin panelindeki bakiyeyle her gün küçük farklar üretir. İptal edilen sipariş, iade edilen kod, elle yapılan düzeltme, kur çevrimi, komisyon kesintisi. Tek tek bakıldığında hepsi küçüktür. Haftalık mutabakatta bu farklar birikir ve hangi işlemden geldiğini bulmak saatler alır.
Günlük mutabakat ise farkı doğduğu gün yakalar. Yöntem basit: gün sonunda tedarikçinin hareket dökümünü çek, kendi işlem kayıtlarınla referans numarası bazında eşleştir, eşleşmeyenleri ayrı bir kuyruğa düşür. Bu kuyruk her sabah boşaltılıyorsa, ay sonunda mutabakat diye bir iş kalmaz. Dijital ürün satış scripti tarafında aranacak özellik şudur: hareket dökümünü otomatik çekip farkları listeleyebiliyor mu, yoksa Excel'e mi bırakıyor?
Hangi kontrolleri bugün işaretleyebilirsin?
Bakiye takibini düzeltmek büyük bir proje değil; doğru sırayla yapılmış birkaç ayar. Aşağıdaki liste, bakiye kaynaklı teslimat hatalarının neredeyse tamamını kapatır.
| Kontrol maddesi | Neye yarar | Öncelik |
|---|---|---|
| Bakiyeyi "kalan süre" olarak gösterme | Karar verdiren metriği öne çıkarır | Yüksek |
| Üç seviyeli eşik ve ayrı kanallar | Yükleme için gerçek zaman kazandırır | Yüksek |
| Sipariş anında rezerve/blokaj | Yoğun saatte kısmi teslimatı önler | Yüksek |
| Günlük otomatik mutabakat kuyruğu | Farkı doğduğu gün yakalar | Orta |
| Kur bazlı bakiye çevrimi kaydı | Marjın nerede eridiğini gösterir | Orta |
| Bakiye hareketlerinde değiştirilemez log | Anlaşmazlıkta ispat sağlar | Yüksek |
"Bakiye 5.000 TL altına inerse uyar" kuralı sakin günde erken, kampanya gününde çok geç çalışır. Doğrusu son 24 saatin satış hızını baz alan dinamik eşiktir: eşik = ortalama saatlik harcama x hedef güvenlik süresi. Aynı kural her iki günde de doğru zamanda tetikler.
Bakiye verisi başka hangi kararları besler?
Bakiye takibi düzgün kurulduğunda elinde beklenmedik bir veri seti oluşur: tedarikçi bazlı gerçek harcama hızı. Bu veri pazarlık masasında en güçlü kozundur. "Ayda şu kadar ciro yapıyorum" demek yerine "bu ürün grubunda haftada 180 bin TL alım geçiriyorum, iskonto oranını konuşalım" demek tamamen başka bir konuşmadır.
İkinci fayda nakit planlamasıdır. Harcama hızını bilmek, ne zaman ne kadar transfer yapacağını bilmek demektir; bu da gereksiz yere tedarikçide kilitli duran parayı serbest bırakır. Pinova'nın bakiye modülü bu iki çıktıyı da rapora çevirir; hangi paketin hangi raporu kapsadığını fiyat bölümünde, modülün kapsamını ise özellikler listesinde görebilirsin.
Bakiyeni sayı olarak değil süre olarak gör
Pinova; kalan süre hesabı, üç seviyeli eşik uyarısı, sipariş anında rezerve bakiye ve günlük mutabakat kuyruğunu tek panelde birleştirir.
Tedarikçi API'si bakiye sorgusu vermiyorsa ne yapılır?
Bu durumda bakiye yerel olarak izlenir: başlangıç tutarı girilir, her başarılı siparişin alış maliyeti düşülür, yüklemeler elle eklenir. Yerel sayaç günlük mutabakatla doğrulanır.
Rezerve bakiye müşteriye yansır mı?
Yansımaz. Blokaj tamamen tedarikçi tarafındaki kullanılabilir bakiye hesabını korumak içindir; müşteri arayüzünde ne tutar ne süre olarak görünür.
Kur farkı bakiyeyi nasıl etkiler?
Dövizli tedarikçide bakiye sabit kalsa bile TL karşılığı değişir. Bu yüzden kalan süre hesabı, bakiyenin güncel kurla çevrilmiş TL değeri üzerinden yapılmalı ve her çevrim kaydı loglanmalıdır.
Kaç tedarikçide bakiye tutmak mantıklı?
Aktif kullandığın her tedarikçide en az bir günlük satış hacmi kadar bakiye tutmak yeterlidir. Fazlası, kilitli sermaye demektir; azı ise kampanya saatinde satış kaybı.
Bakiye ekranının süre bazlı gösterimi, eşik renkleri ve rezerve kolonu gerçek panelde bambaşka okunuyor. Kendi tedarikçi tablonu zihninde kurmak için canlı demo içindeki bakiye modülünü aç, sonra bu yazıdaki kontrol listesini kendi kurulumuna uygula.