Çoğu satıcı bakiye sistemini şöyle görür: "Müşteri hesabına para yükledi, para bankaya geçti, ciro oldu." Bu bakış ilk aylarda sorun çıkarmaz. Sonra bir gün otuz bin liralık bakiye biriktiğinde, ay sonu raporunda kâr görünürken kasada o paranın büyük kısmının aslında henüz senin olmadığını fark edersin. Çünkü müşteri o bakiyeyi henüz hiçbir ürüne dönüştürmedi. İstediği an harcayabilir, bazı durumlarda iade talep edebilir.
İşte bu yüzden ciddi işletmelerde müşteri bakiyesi ciroya değil, emanet mantığına yazılır: bir yükümlülük kalemi, henüz hak edilmemiş bir tahsilat. Kulağa muhasebeci detayı gibi geliyor ama sonucu çok pratik: bakiyeyi gelir sayan satıcı elindeki nakdi işletme sermayesi sanır, harcar ve müşteriler aynı hafta bakiye kullanmaya başladığında tedarikçiye ödeyecek parası kalmaz. Aşağıda bu ayrımı e-pin satış scripti tarafında nasıl kuracağını, hangi raporu tutacağını ve mali müşavirine ne vereceğini adım adım anlatıyorum.
Bakiye Yüklemesi Gelir Değilse Nedir?
Müşteri hesabına para yüklediğinde ortaya bir takas çıkmaz. Sen bir mal teslim etmedin, bir hizmet vermedin. Sadece ileride kullanılmak üzere para aldın. Ticari mantıkta bunun karşılığı alınan avans yani bir borç kalemidir. Müşteri o parayı bir kod satın almak için kullandığında, işte o anda gerçek bir satış doğar ve o tutar emanetten çıkıp gelire geçer.
Bu ayrımın somut faydası şudur: hangi ayın gerçekten kârlı olduğunu görürsün. Ocak ayında yüz bin lira bakiye yüklenmiş, şubatta harcanmışsa, bakiyeyi gelir sayan sistem ocağı harika, şubatı felaket gösterir. Oysa gerçek satış şubatta olmuştur. Dijital ürün satış yazılımının raporlarının işe yarar olması, tam olarak bu zamanlamayı doğru kurmasına bağlıdır. Vergi ve fatura tarafındaki tam uygulama için mali müşavirinle konuşmalısın; her işletmenin mükellefiyeti ve kayıt düzeni farklı olabilir. Burada anlattığım şey, yazılım tarafında verinin nasıl tutulması gerektiğidir.
Emanet Defterini Script İçinde Nasıl Kurarsın?
Tek bir "bakiye" alanı yeterli değildir. Kullanıcı tablosunda duran bir sayı, nasıl o hale geldiğini anlatmaz. Doğru yapı bir hareket defteridir: her yükleme, her harcama, her iade, her düzeltme ayrı bir satır olarak yazılır ve bu satırlar asla silinmez, sadece ters kayıtla düzeltilir. Kullanıcının o anki bakiyesi bu satırların toplamıdır. Böylece "bakiyem eksik" şikâyetine tek sorguyla cevap verirsin.
Her satırda bulunması gereken alanlar şunlar: tarih, tür (yükleme/harcama/iade/manuel düzeltme), tutar, işlem sonrası bakiye, kaynak referansı (ödeme kimliği veya sipariş numarası), işlemi yapan (müşteri mi yönetici mi) ve varsa açıklama. Manuel düzeltmelerde kimin yaptığının kaydı özellikle kritik: çok kullanıcılı bir panelde bakiye ekleme yetkisi, denetim izi olmadan verilirse ciddi bir risktir. Pinova'nın bakiye modülü bu yüzden hareketleri değiştirilemez satırlar olarak tutar ve manuel işlemleri ayrı bir kategoride etiketler.
| Olay | Emanet (yükümlülük) | Gelir | Kasa / banka |
|---|---|---|---|
| Müşteri 500 ₺ bakiye yükledi | +500 | 0 | +500 |
| Bakiyeden 200 ₺ kod aldı | −200 | +200 | 0 |
| Kod teslim edilemedi, iade | +200 | −200 | 0 |
| Müşteri 300 ₺ bakiyeyi geri istedi | −300 | 0 | −300 |
| Kampanya bonusu 25 ₺ verildi | +25 (promosyon) | 0 | 0 |
| Bonus harcandı | −25 | +25 (indirim gideri ile) | 0 |
Bonus Bakiye Neden Ayrı Kovada Durmalı?
Tablodaki son iki satır çoğu kurulumda hatalı işler. Kampanya için verdiğin 25 liralık bonus, müşterinin yüklediği parayla aynı havuzda tutulursa iki sorun doğar. Birincisi kasa mutabakatı bozulur: sistemde toplam bakiye görünenden fazla çıkar, çünkü bonusun bankada karşılığı yoktur. İkincisi iade talebinde karışıklık olur — müşteri bonusu da nakit olarak geri isteyebilir ve elinde net bir ayrım yoksa tartışmayı kaybedersin.
Çözüm, bakiyeyi iki kovaya bölmektir: nakit bakiye (gerçekten ödenen, iade edilebilir) ve promosyon bakiyesi (senin verdiğin, nakde çevrilemez, süresi olabilir). Harcama sırasında hangisinin önce tükendiğini de kuralla belirlersin; genelde promosyonun önce harcanması hem müşteri lehine görünür hem senin yükümlülüğünü azaltır. Bu ayrım kurulmadan yapılan hiçbir kampanya sağlıklı ölçülemez, çünkü verdiğin indirimin maliyetini gelirden ayırt edemezsin.
Tipik bir satıcıda toplam müşteri bakiyesinin bileşimi
- Aktif nakit emanet 52%
- Uzun süre hareketsiz bakiye 22%
- Promosyon / bonus bakiye 17%
- İade bekleyen tutarlar 9%
Mutabakat: Sistemdeki Toplam ile Bankadaki Para Uyuşuyor mu?
Emanet mantığının tek somut testi budur. Günün sonunda sistemdeki nakit bakiye toplamını al, buna henüz teslim edilmemiş siparişlerin karşılığını ekle ve bankadaki tutarla karşılaştır. Banka tarafı daha azsa tehlikedesin: müşteri emanetini işletme gideri olarak harcamışsın demektir. Bu, işi büyütürken en sık yapılan ve en sessiz ilerleyen hatadır; nakit akışı bir gün duvara çarpana kadar kimse fark etmez.
Sağlıklı pratik, emanet karşılığını ayrı bir hesapta tutmak veya en azından asla o tutarın altına düşmeyecek bir taban belirlemektir. Yazılım tarafında yapılacak şey ise mutabakat raporunu otomatikleştirmek: her gün toplam emanet, toplam teslim edilmemiş sipariş ve bunların değişimini gösteren tek bir ekran. Sapma bir eşiği geçtiğinde bildirim gönder. Bir epin yazılım kurulumunda bu rapor, kâr raporundan daha kritiktir; çünkü kâr yanlış hesaplanırsa moral bozulur, emanet karışırsa iş durur.
Eşzamanlı iki isteğin aynı bakiyeyi harcaması klasik bir yarış durumudur. Harcama işlemini kilitli ve tek işlemde yap, bakiye kontrolünü düşüşle aynı sorguda uygula. Aksi halde 100 liralık bakiyeyle 200 liralık ürün teslim edilir ve kaybı sen karşılarsın.
Hareketsiz Bakiye ve İade Talepleri: Politikanı Yazılı Kur
Yıllarca dokunulmayan bakiyeler zamanla birikir ve belirsiz bir yükümlülük oluşturur. Burada kendi kafana göre kural koymak yerine iki şeyi yapmalısın: politikayı kullanım koşullarında açıkça yazmak ve uygulamayı mali müşavirinin yönlendirmesiyle belirlemek. Yazılım tarafında ihtiyacın olan şey esneklik: hareketsizlik süresini ölçen bir alan, müşteriye hatırlatma gönderme imkânı ve gerektiğinde bakiyeyi işaretleyip raporlayabilme.
İade tarafında ise süreç net olmalı. Talep geldiğinde hangi kovadan ne kadar iade edilebileceği, hangi ödeme yoluna geri döneceği ve bu işlemin hareket defterine nasıl yazılacağı önceden tanımlı olmalı. "Duruma göre bakarız" yaklaşımı, kayıtları bozan manuel müdahalelerle sonuçlanır. Pinova'da iade işlemi ayrı bir hareket türü olarak geçtiği için, ay sonunda iade hacmini ve bunun net kâra etkisini ayrı bir satırda görürsün. Özellikler bölümünde bakiye ve iade akışının hangi alanları tuttuğunu inceleyebilirsin.
| Kontrol maddesi | Neden gerekli? | Durum |
|---|---|---|
| Nakit ve promosyon bakiyesi ayrı | Mutabakat ve iade netliği | Zorunlu |
| Silinemeyen hareket defteri | Şikâyette kanıt, denetimde iz | Zorunlu |
| Kilitli harcama işlemi | Negatif bakiye ve çift harcamayı engeller | Zorunlu |
| Günlük emanet-kasa mutabakatı | Müşteri parasını farkında olmadan harcamamak | Zorunlu |
| Manuel bakiye işleminde kullanıcı kaydı | Çok kişili panelde iç risk kontrolü | Zorunlu |
| Gelir tanıma anı = teslim anı | Aylık raporun gerçeği göstermesi | Yüksek |
| İade politikası ve akışı tanımlı | Manuel müdahaleleri azaltır | Yüksek |
| Mali müşavire aylık emanet dökümü | Kayıtların doğru kapanması | Yüksek |
Mali Müşavirine Tam Olarak Neyi Vermelisin?
Ekran görüntüsü ve "şu kadar bakiye var" cümlesi yetmez. Ay sonunda üç döküm hazırla. Birincisi dönem başı ve dönem sonu emanet bakiyesi ile arasındaki hareket özeti. İkincisi bakiyeden gerçekleşen satışların listesi, yani emanetten gelire dönüşen tutarlar. Üçüncüsü iadeler ve promosyon kullanımları. Bu üç döküm bir araya geldiğinde kayıtlar tek seferde, soru-cevap trafiği olmadan kapanır.
Bu dökümleri elle hazırlamak zorunda kalıyorsan sistem eksik kurulmuş demektir. Dijital ürün satış scripti bu raporları tek tuşla üretmeli ve tarih aralığı seçilebilmeli. Zaman kazancının ötesinde bir faydası var: rakamlar her ay aynı yöntemle üretildiği için dönemler karşılaştırılabilir hale gelir ve büyümenin gerçekten nereden geldiğini görürsün.
Müşteri parasını kendi paranla karıştırma
Ayrı kovalar, silinemeyen hareket defteri, günlük mutabakat ve tek tuş emanet dökümü. Pinova bakiyeyi bir sayı değil, denetlenebilir bir defter olarak yönetir.
Bakiye yüklendiği anda fatura kesmem gerekir mi?
Bu, mükellefiyet ve kayıt düzenine bağlı bir konu; net cevabı mali müşavirin verir. Yazılım tarafında yapman gereken, yükleme ile kullanım anlarını ayrı ayrı kaydetmek ve ikisini de raporlanabilir tutmak.
Promosyon bakiyesi iade edilir mi?
Genellikle hayır, çünkü karşılığında bir ödeme alınmamıştır. Ancak bunu kullanım koşullarında açıkça yazmalısın; yazılı olmayan kural tartışmada işine yaramaz.
Bakiye toplamı bankadakinden fazla çıkarsa ne yapmalıyım?
Önce promosyon bakiyesinin karıştırılıp karıştırılmadığını kontrol et. Ayrım doğruysa gerçekten emaneti harcamış olabilirsin; nakit planını buna göre düzeltmen gerekir.
Müşteri bakiyesini başka birine devredebilir mi?
Teknik olarak mümkün ama önerilmez. Devir, kötü amaçlı kullanım ve izlenebilirlik sorunları açar. Zorunluysa mutlaka hareket defterine iki ayrı satır olarak ve kayıtlı gerekçeyle işlensin.
Bakiye sistemi, doğru kurulduğunda hem tahsilat maliyetini düşüren hem nakit akışını öne çeken güçlü bir araçtır; yanlış kurulduğunda ise büyüdüğünü sanırken nakit sıkıştıran sessiz bir tuzak. Farkı yaratan şey karmaşık muhasebe değil, iki kovayı ayırmak ve her hareketi yazmak. Bu yapının panelde nasıl göründüğünü, mutabakat ekranını ve emanet dökümünü kendi verinle test etmek istersen canlı demo üzerinden bakiye modülünü inceleyebilir, uygun lisans için fiyat bölümüne bakabilirsin.