E-pin Yazılımında Ay Sonu Kapanışını Herkes Excel'de Yapıyor Sanıyorsun: İşte Kâr Eden Bayilerin Kimseye Anlatmadığı 7 Günlük Kapanış Ritüeli

Çoğu e-pin bayisi ay sonu kapanışını muhasebecinin işi sanır. Ayın son günü panelden bir satış raporu indirilir, banka ekstresi yanına açılır, aradaki fark "herhalde iade vardır" diye geçilir ve dosya kapanır. Oysa bu sektörde ay sonu, muhasebe işlemi değil operasyon teşhisidir. Çünkü senin işinde stok fiziksel değil; stok bir karakter dizisi. Kaybolduğunda rafta boşluk görmezsin, sadece kârın erir.

Gerçek şu: düzgün kurulmuş bir e-pin satış yazılımı ay sonunda sana dört ayrı hakikat sunar; sipariş hakikati, kod hakikati, tahsilat hakikati ve tedarikçi hakikati. Bu dördü birbirini tutmuyorsa sorun muhasebede değil, akışın içindedir. Aşağıda, cirosu benzer iki bayiden birinin neden kâr ederken diğerinin neden sürekli "para nereye gitti" dediğini adım adım açıyorum.

Neden "ayın son günü" kapanış yapmak en kötü fikir?

Ay sonu kapanışı tek güne sıkıştırıldığında, çıkan farkları düzeltecek zaman kalmaz. Bankadan gelen ödeme mutabakat dosyası genelde ertesi iş gününde netleşir; tedarikçinin ekstresi ise çoğu zaman ayın ilk haftasında gelir. Sen 31'inde raporu kapatırsan, 3'ünde gelen 4 bin liralık komisyon farkı "geçen ay" değil, yeni ayın gideri olur. Bir yıl sonra hangi ayın gerçekten kârlı olduğunu söyleyemezsin.

Sağlıklı model şudur: kapanış, ayın son iki günü ile yeni ayın ilk beş günü arasına yayılır. Bu yedi günde kayıtlar aşama aşama kilitlenir. Önce sipariş defteri, sonra stok defteri, sonra tahsilat, en sonda tedarikçi maliyeti. Kullandığın dijital ürün satış scripti her aşamada bir önceki aşamayı dondurabiliyorsa, geriye dönük veri kayması yaşamazsın.

Dört defter neden birbirini tutmuyor?

Sipariş sayısı ile teslim edilen kod sayısı arasındaki fark, sektörün en sessiz para sızıntısıdır. Bir siparişte üç kod teslim edilmesi gerekirken iki kod gitmişse, müşteri yazar ve sen elle bir kod daha verirsin. O elle verilen kod çoğu zaman hiçbir defterde gideri olmayan bir maliyet olarak kalır. Ay sonunda stokta eksik görünür ama satışta karşılığı yoktur.

Aynı şekilde tahsilat defteri ile sipariş defteri de nadiren birebir eşleşir. Ödeme kuruluşu komisyonu, taksit farkı, chargeback, kısmi iade ve bekleyen ödeme kalemleri araya girer. Doğru kurulan bir e-pin scripti bu kalemlerin her birini ayrı satır olarak tutar ve brütten nete inen bir köprü raporu üretir. Köprü raporu yoksa, her ay tahminle çalışıyorsun demektir.

Kod maliyetini ortalamayla hesaplamak seni neden yanıltıyor?

Pek çok bayi kâr hesabını "ortalama alış - ortalama satış" üzerinden yapar. Bu, kur hareketli ve parti bazlı alım yapılan bir işte ciddi bir yanılgıdır. Aynı ürünün üç ayrı partisi üç ayrı maliyete sahiptir; ucuz partiyi satarken yüksek kâr, pahalı partiyi satarken zarar edersin. Ortalama bu ikisini birbirine yedirir ve sen bir ürünün aslında zarar ettiğini asla göremezsin.

Çözüm, kod havuzunu parti (lot) bazlı tutmak ve satışta hangi partiden düşüldüğünü kayıt altına almaktır. Modern bir epin yazılım altyapısında her kodun bir alış fiyatı, bir alış tarihi ve bir tedarikçi etiketi olur. Böylece ay sonunda ürün bazlı değil, parti bazlı brüt kâr görürsün. Hangi tedarikçinin son üç aydır seni sessizce zarara soktuğu ancak bu şekilde ortaya çıkar.

Kapanışı kim yapmalı: sen mi, sistem mi?

Kapanışın elle yapılan kısmı ne kadar büyükse, ay sonu o kadar korkulan bir gün haline gelir. Bunun sonucu da öngörülebilir: kapanış ertelenir, ertelendikçe veri bulanıklaşır. Doğru kurgu, sistemin kapanışın %80'ini otomatik üretmesi, senin ise sadece istisnaları onaylamandır. İstisna, tanımı gereği azdır; azsa da incelenebilir.

Pratikte bu şu demek: yazılım ay bittiğinde sana on beş sayfalık rapor değil, üç satırlık bir istisna listesi vermeli. "Şu 6 sipariş hâlâ bekliyor", "şu 11 kod elle teslim edilmiş", "şu tedarikçi faturası eşleşmedi". Bu üç satırı temizlediğinde kapanış biter. Özellik listesinde raporlama tarafını incelerken tam olarak bu istisna mantığının olup olmadığına bak.

Kapanıştan çıkan üç karar hangileri?

Kapanış, rapor üretmek için değil karar vermek için yapılır. Doğru işlemiş bir ay sonundan en az üç somut karar çıkmalıdır. Birincisi fiyat kararıdır: brüt kâr marjı hedefinin altına düşen ürünlerde ya satış fiyatı yükselir ya tedarikçi değişir. İkincisi tedarikçi kararıdır: teslim gecikmesi, hatalı kod oranı ve kur davranışı birlikte değerlendirilir.

Üçüncüsü ise ürün gamı kararıdır. Her ay cironun yüzde birini bile oluşturmayan, buna karşılık destek talebinin önemli bölümünü üreten ürünler vardır. Bunlar kataloğu şişirir, operasyonu yorar ve görünmez maliyet üretir. Kapanış tablonda "ciro payı" ile "destek payı" yan yana duruyorsa, bu kararı vermek bir dakika sürer. Paket karşılaştırmasında raporlama derinliğinin neden fiyat farkı yarattığını da böyle anlarsın.

Yedi günlük kapanış ritüeli pratikte nasıl işler?

Ritüelin özü basit: her gün tek bir defteri kapatırsın ve o defteri bir daha açmazsın. Birinci gün siparişler, ikinci gün stok, üçüncü gün tahsilat, dördüncü ve beşinci gün tedarikçi, altıncı gün konsolidasyon, yedinci gün karar toplantısı. Tek kişiysen toplantı on beş dakikalık bir not almaktır; ekipsen aynı notu ekiple paylaşırsın.

Bu ritüelin en büyük faydası psikolojiktir. Ay sonu artık korkulan bir gün değil, öngörülebilir bir rutindir. Rutin olduğu için de aksamaz; aksamadığı için veri birikir. Altı ay sonra elinde, hangi ürünün hangi sezonda nasıl davrandığını gösteren gerçek bir tarih serisi olur. İşte sektörde kalıcı olan bayiler ile bir yılda kaybolanları ayıran fark tam olarak bu birikimdir.

Ay sonu kapanışı, yazılımının sana ne kadar dürüst olduğunu test eden tek gerçek sınavdır. Panelin bu sınavı geçemiyorsa her ay biraz daha körleşirsin. Kapanışın nasıl kilitlendiğini, istisna listesinin nasıl göründüğünü ve parti bazlı kâr tablosunun neye benzediğini kendi gözünle görmek istersen canlı demo üzerinden birkaç dakikada deneyebilir, ardından paket seçimine geçebilirsin.