Bayi Cari Hesabını Excel'de Tutuyorsan Her Ay Sessizce Para Kaybediyorsun: Mutabakat Raporunun Kimsenin Anlatmadığı Gizli Mantığı

Çoğu e-pin satıcısı bayi cari hesabını muhasebe işi sanır. "Bayiye ne kadar yükledim, ne kadar harcadı, farkı da not ettim" der ve konuyu kapatır. Oysa bayilik sisteminde cari hesap muhasebe kalemi değil, işletmenin en kırılgan güven noktasıdır. Bayiyle aranda bir fiyat tartışması çıktığında elinde ne varsa, o an haklı olan taraf odur. Elinde tek sütunlu bir Excel varsa, tartışmayı otomatik kaybediyorsun.

İşin sessiz kısmı şu: kaybettiğin para çalınmıyor, eriyor. İade edilmiş ama bakiyeye geri yazılmamış bir sipariş, iki kere işlenmiş bir bakiye yüklemesi, teslim edilmemiş ama ücreti düşülmüş bir kod, elle verilmiş bir "gönül indirimi"... Bunların tek tek tutarı küçüktür, ama ay sonunda toplamı senin net kârına oturur. Bu yazıda bayi cari hesabının gerçekte nasıl çalıştığını, mutabakat raporunun neyi kanıtladığını ve bir e-pin scripti üzerinde bu düzenin nasıl kurulduğunu adım adım açacağız.

Excel'deki cari hesap neden matematiksel olarak yanlış?

Excel'in sorunu formül değil, zaman. Bir tabloda "bakiye" hücresi tek bir andaki fotoğraftır; nasıl o değere geldiğini göstermez. Bayi seni arayıp "ben dün 4.000 TL yüklemiştim, bakiyem neden 3.200?" dediğinde cevap verebilmen için bakiyeyi değil, bakiyeye giden hareket zincirini görmen gerekir. Excel'de bu zincir yoktur, çünkü her düzeltme eski değeri siler.

İkinci sorun eşzamanlılıktır. Bayi panelden sipariş verirken sen aynı satırı düzenliyorsan, biriniz diğerinin yazdığını eziyor. Doğru mimari, bakiyeyi hiç "yazmaz": bakiye, hareket kayıtlarının toplamı olarak hesaplanır. Buna muhasebede defter mantığı denir ve iyi bir dijital ürün satış scripti tam olarak bunu yapar. Bakiye bir sonuçtur, veri değil.

Üçüncüsü ise geri alınamazlıktır. Ciddi bir e-pin satış yazılımı hiçbir hareketi silmez; yanlış kaydı ters kayıtla düzeltir. Yani 500 TL'lik hatalı düşümü silmek yerine, +500 TL'lik bir "düzeltme" hareketi yazar ve nedenini not eder. Böylece geçmiş bozulmaz, denetlenebilir kalır.

Bakiye hangi anda düşmeli: sipariş mi, teslim mi?

Bu, bayilik sisteminin en çok kan kaybettiren sorusudur. Sipariş anında düşersen, stok yetmediğinde bayinin parası havada kalır ve güven kırılır. Teslim anında düşersen, aynı bakiyeyle eşzamanlı iki sipariş girilebilir ve bakiye eksiye düşer. Doğru cevap ikisi de değil: üç adımlı akış.

Sipariş anında tutar bloke edilir; kullanılabilir bakiyeden düşer ama harcanmış sayılmaz. Kod teslim edildiğinde bloke, gerçek düşüme dönüşür. Teslim başarısızsa bloke serbest bırakılır. Bu üç durumu ayrı hareket tipi olarak tutmayan bir epin yazılım kurulumunda, ay sonunda bayinin rakamıyla senin rakamın asla örtüşmez.

Kritik detay: bloke süresi sonsuz olmamalı. Beklemede kalan bir sipariş 30 dakika sonra otomatik serbest bırakılmalı ve bayiye bildirilmeli. Aksi halde bayinin parası "görünmez şekilde" kilitli kalır; bu, bayinin seni bırakmasının bir numaralı sessiz sebebidir.

Mutabakat raporu aslında bakiyeyi mi ölçer?

Hayır. Mutabakat raporu bakiyeyi değil, iki tarafın aynı gerçeği görüp görmediğini ölçer. Bu yüzden tek sayı içeren bir mutabakat işe yaramaz. Doğru rapor dört bileşen taşır: dönem başı bakiye, dönem içi hareketler, dönem sonu bakiye ve farkın gerekçesi. Dördüncüsü olmadan rapor bir belge değil, iddiadır.

İyi bir mutabakat çıktısı bayinin muhasebecisinin anlayacağı dilde olmalı: tarih, açıklama, borç, alacak, yürüyen bakiye. Yürüyen bakiye sütunu şart; çünkü anlaşmazlık genelde tüm dönemde değil, tek bir satırda çıkar. Yürüyen bakiye sayesinde tartışma "hangi gün ayrıştık?" sorusuna indirgenir ve iki dakikada çözülür.

Raporun PDF olarak dondurulup saklanması da ayrı bir zorunluluktur. Bayi altı ay sonra geri döndüğünde, o günkü tabloyu yeniden üretmek yerine imzalanmış çıktıyı gösterirsin. Bir e-pin satış scripti kurarken "mutabakat ekranı" yeterli değil; mutabakat arşivi gerekir.

Yaşlandırma tablosu olmadan bayiye limit vermek neden kumardır?

Vadeli çalışan bayilerde tek bir "alacak" toplamı yanıltıcıdır. 40.000 TL alacağın varsa ama bunun 32.000'i 60 günü geçmişse, o bayinin ödeme gücü değil ödeme niyeti sorunlu demektir. Alacak yaşlandırma tablosu alacağı 0-7, 8-30, 31-60 ve 60+ gün kovalarına böler. Karar bu kovalardan çıkar, toplamdan çıkmaz.

Limit de statik olmamalı. Sağlıklı bir kurulumda limit üç veriden türer: bayinin son 90 günlük hacmi, ortalama ödeme günü ve gecikme sayısı. Bu üçlüyü panelde gören bir dijital ürün satış yazılımı kullanıyorsan, limit artırma kararını duyguyla değil skorla verirsin. Bayi "abi limitimi artır" dediğinde elinde tartışılmaz bir gerekçe olur.

Otomatik mutabakat kurulumu pratikte neye benzer?

Pinova gibi bir bayi altyapısı kurarken hedef, mutabakatı insan işi olmaktan çıkarmaktır. Sistem her hareketi tek bir defter tablosuna yazar, bakiyeyi bu tablodan hesaplar, haftalık olarak bayiye dönem raporu üretir ve fark oluştuğunda senin onayına düşen bir uyarı açar. Böylece ay sonu 3 saatlik iş, 10 dakikalık kontrole iner.

İkinci katman erişimdir. Bayi kendi hareketlerini panelden her an görebiliyorsa, sana gelen "bakiyem ne?" mesajlarının neredeyse tamamı kaybolur. Bu yalnızca destek yükünü değil, güven algısını da değiştirir: kayıtlarını açık tutan tedarikçi güvenilir sayılır. Özellikler tarafında bayi cari ekranını ve rapor arşivini birlikte değerlendirmen gerekir.

Üçüncü katman ise yetkidir. Manuel düzeltme herkese açık olmamalı; gerekçe zorunlu, kullanıcı kaydı zorunlu, tutar eşiği üstünde ikinci onay zorunlu olmalı. Bu üç kural yazılımda bir kez kurulduğunda, cari hesap hatası kişisel dikkat meselesi olmaktan çıkar.

Bayi ilişkisi fiyatla değil kayıtla ayakta kalır. Cari hesabını defter mantığıyla kuran, blokeyi ayıran ve mutabakatı otomatik gönderen bir altyapıya geçtiğinde hem ay sonu stresin hem de sessiz para kaybın biter. Bu düzenin gerçek bir panelde nasıl göründüğünü görmek istiyorsan canlı demo üzerinden bayi cari ekranını ve mutabakat arşivini kendin gez, ardından fiyat tarafında kendi hacmine uyan paketi seç.