Dönem sonu geliyor, muhasebecin tek bir cümle yazıyor: "Bu ayın satış toplamını gönder." Sen panele giriyorsun, tarih filtresini ayın birinden sonuna kuruyorsun, çıkan rakamı kopyalayıp gönderiyorsun. İki gün sonra telefon çalıyor: rakamlar tutmuyor. Çoğu satıcı bu noktada scripti suçlar ya da muhasebecinin farklı bir şeye baktığını düşünür. Gerçek çok daha sıradan: panelin gösterdiği "ciro" ile vergi döneminin tanımladığı "satış" aynı şey değil.
Aradaki fark tek bir teknik soruda toplanır: bir siparişi hangi ana göre döneme yazıyorsun — sipariş oluştuğu an mı, ödeme onaylandığı an mı, yoksa kod teslim edildiği an mı? Epin satışında bu üç zaman damgası genelde aynı güne düşer ama ayın son gecesinde, iade edilen bir siparişte veya gece yarısı ödemesi sabah teslim edilen bir üründe üçü ayrılır. İşte dönem sonu kâbusu tam bu ayrılıktan doğar. Bu yazıda bir epin satış scripti içinde vergi dönemine göre satış özetini nasıl kuracağını, hangi kalemleri ayrı raporlaman gerektiğini ve dönemi kapattıktan sonra rakamların neden hiç değişmemesi gerektiğini anlatıyorum.
Panelde yazan ciro neden muhasebe rakamı değil?
Panel cirosu genellikle satışın brüt ve işletme gözüyle görünen hâlidir: müşterinin ödediği toplam tutar. Muhasebe tarafında ise bu tutar birkaç parçaya ayrılır. Vergi bileşeni ayrılır, ödeme sağlayıcısının kestiği komisyon bir gider kalemi olur, iade edilen tutarlar negatif olarak işlenir, bakiye ile yapılan alışverişte ise paranın işletmeye giriş anı ile ürünün satıldığı an birbirinden ayrılır.
Bu yüzden "tek bir ciro rakamı" göndermek en baştan hatalıdır. İyi kurulmuş bir dijital ürün satış yazılımı dönem özetini tek sayı olarak değil, birbirini toplayan bir kalem listesi olarak verir: brüt satış, iade ve iptaller, net satış, vergi bileşeni, ödeme komisyonları, bakiye yüklemeleri ve dönem sonunda kullanılmamış bakiye bakiyesi. Muhasebecin bu listeye baktığında ek soru sormaz, çünkü her satırın karşılığı defterde bir yere oturur. Dönem özetinin kalitesi, satır sayısıyla doğru orantılıdır.
Dönem hangi tarihe göre kapanır: sipariş, ödeme yoksa teslim?
Bu, yazının en kritik başlığı. Üç aday tarih var ve hangisini seçtiğin bir tercih değil, bir tutarlılık meselesidir. Sipariş tarihi müşterinin talebi oluşturduğu andır; ödeme tarihi paranın onaylandığı andır; teslim tarihi kodun müşteriye ulaştığı andır. Epin işinde bu üçü genellikle dakikalar içinde gerçekleşir, ama ayın son gecesi saat 23:55'te ödenen ve 00:04'te teslim edilen bir sipariş iki farklı döneme yazılabilir.
Pratikte en az sürprizli yaklaşım, dönem raporunu ödemenin onaylandığı tarihe göre kurmak ve teslim tarihini ayrı bir kolon olarak tutmaktır. Böylece finansal rapor paranın hareketini, operasyon raporu ise teslimatı izler. Ama burada tek doğru cevap kanuni ve sektörel ayrıntılara bağlıdır; hangi tarihi esas alacağını mutlaka mali danışmanınla birlikte belirle. Senin işin, scriptin bu tercihi destekleyebildiğinden ve seçim yapıldıktan sonra hiç değişmediğinden emin olmaktır. Dönem esasını her ay farklı yorumlamak, en iyi yazılımı da işe yaramaz hâle getirir.
| Dönem özeti kalemi | Kaynak veri | Neden ayrı gösterilir | Sık yapılan hata |
|---|---|---|---|
| Brüt satış | Onaylı sipariş toplamı | Hacmin ham göstergesi | İadeler düşülmeden gönderilmesi |
| İade ve iptal | İade kayıtları | Negatif kalem olarak izlenmeli | Sipariş tarihine değil iade tarihine yazmamak |
| Net satış | Brüt eksi iade | Dönemin gerçek satış hacmi | Komisyonun burada düşülmesi |
| Vergi bileşeni | Sipariş bazlı oran | Ürün gruplarında oran farkı olabilir | Tüm ürünlere tek oran uygulamak |
| Ödeme komisyonu | Sağlayıcı raporu | Gider kalemidir, satış indirimi değil | Cirodan düşüp net satış sanmak |
| Bakiye yüklemeleri | Cüzdan hareketleri | Tahsilat ile satış farklı anlarda | Yüklemeyi satış olarak saymak |
| Kullanılmamış bakiye | Dönem sonu cüzdan toplamı | Yükümlülük niteliği taşır | Hiç raporlamamak |
İade, iptal ve kısmi teslimat dönemi nasıl bozar?
Dijital üründe iade fiziksel üründeki gibi kargo bekleyip gelen bir şey değildir; kod çalışmadığında, yanlış bölgeye ait olduğunda veya çift sipariş oluştuğunda anında yapılır. Sorun, iadenin hangi döneme yazıldığında çıkar. Ayın son günü satılan ve ertesi ayın ikinci günü iade edilen bir sipariş, iki dönemi birbirine karıştırır: birinci dönem olduğundan fazla satış gösterir, ikinci dönem ise negatif bir kalemle açılır.
Bu bozulmanın önüne geçmenin yolu iadeyi orijinal siparişin tarihine değil, iadenin gerçekleştiği tarihe yazmak ve dönem özetinde iadeyi ayrı bir satır olarak göstermektir. Kısmi teslimatta ise kural daha da net olmalı: on kodluk siparişin altısı teslim edildiyse, dönemde teslim edilen altı kod raporlanır, kalan dördü açık yükümlülük olarak taşınır. Bir e-pin scripti kısmi teslimatı tek bir "tamamlandı" bayrağına indiriyorsa, dönem özetin daima gerçekten sapar.
Dönem sonu sapmasının tipik kaynakları
- Yanlış tarih esası (sipariş/ödeme/teslim karışması) 45%
- İade ve iptallerin yanlış döneme yazılması 25%
- Ödeme komisyonunun cirodan düşülmesi 20%
- Bakiye yükleme ile satışın karıştırılması 10%
Brüt ciro seni neden yanıltır: komisyon ve vergi tuzağı
Bir satıcının en sık kurduğu yanlış denklem şudur: panelde 400 bin lira ciro görüyorum, ürün maliyetim 360 bin, demek ki 40 bin kâr ettim. Bu hesapta iki kalem eksik. Birincisi ödeme sağlayıcısının kestiği komisyon; yüzde 2-3 bandında bile 400 bin ciroda 8-12 bin liradır ve bu doğrudan kârdan çıkar. İkincisi vergi bileşeni; ciroyu tamamen kendi gelirin sanmak, aslında en baştan ayrılması gereken bir tutarı harcanabilir para olarak görmektir.
Bu iki kalemi dönem özetinde ayrı satırlara aldığında marj hesabın birden gerçekçi olur ve fiyat kararlarını doğru zeminde verirsin. Pek çok satıcı düşük marjlı ürünlerde aslında zararına sattığını, ancak komisyonu tabloya ekledikten sonra fark eder. Komisyonu göremeyen bir fiyatlandırma, kendi maliyetini bilmeyen bir fiyatlandırmadır. İyi bir e-pin satış yazılımı ürün bazlı komisyon ve maliyet alanlarını tutar, dönem raporunda bunları toplulaştırır.
Dönem kilidi neden şart: kapanan rapor bir daha değişmemeli
Dönemi muhasebecine gönderdin, beyan hazırlandı. Üç hafta sonra aynı tarih aralığını tekrar çalıştırdığında rakam farklı çıkıyor. Sebep basit: geriye dönük bir iade işlendi, bir sipariş durumu elle düzeltildi, bir ürün fiyatı güncellendi ve rapor bu değişiklikleri geçmişe uyguladı. Bu davranış sadece can sıkıcı değil, denetlenebilirliği tamamen yok eder; hangi rakamın gönderildiğini kanıtlayamazsın.
Çözüm dönem kilididir. Dönem kapandığında o aralığa ait rapor anlık görüntü olarak saklanır ve bir daha yeniden hesaplanmaz. Sonradan gelen düzeltmeler yeni döneme "geçmiş dönem düzeltmesi" satırıyla yazılır. Böylece hem kapanmış rakam sabit kalır hem de düzeltmenin izi görünür. Bir epin yazılım altyapısında bu özelliğin varlığını satın almadan önce sormak gerekir; sonradan eklemesi en zor şeylerden biridir, çünkü tüm rapor mantığını etkiler.
| Dönem sonu kontrolü | Neden | Tamam mı? |
|---|---|---|
| Tarih esası yazılı olarak belirlendi | Her dönem aynı mantıkla kapanması için | — |
| Bekleyen ödemeler dönem dışına alındı | Onaylanmamış tahsilat satış sayılmaz | — |
| İadeler kendi tarihine yazıldı | Geçmiş dönemin bozulmaması için | — |
| Kısmi teslimatlar ayrı listelendi | Açık yükümlülüğün görünmesi için | — |
| Ödeme sağlayıcısı raporu panelle eşleştirildi | Eksik veya çift kaydı yakalamak | — |
| Kullanılmamış bakiye toplamı alındı | Cüzdan yükümlülüğünün takibi | — |
| Ürün grubu bazlı vergi oranları doğrulandı | Tek oran varsayımının riskli olması | — |
| Dönem kilitlendi ve özet arşivlendi | Gönderilen rakamın sabit kalması | — |
Kapanışı ayın son gününe bırakmak yerine her hafta bir mini mutabakat yap: sağlayıcı raporu ile panel toplamını karşılaştır. Haftalık farkları bulmak dakikalar sürer; aynı farkı ay sonunda aramak günler sürer.
Dönem kapanışını tek ekrana indir
Pinova, dönem özetini brüt satış, iade, net satış, vergi bileşeni, komisyon ve bakiye kalemleriyle ayrı ayrı üretir; dönem kilidiyle kapanmış raporun bir daha değişmesini engeller.
Dönem raporunu sipariş tarihine göre mi ödeme tarihine göre mi almalıyım?
Finansal raporlarda ödemenin onaylandığı tarih genellikle daha az sürpriz üretir, teslim tarihi ise ayrı bir operasyon kolonu olarak tutulur. Hangi esasın senin için doğru olduğunu mali danışmanınla netleştir ve sonra hiç değiştirme.
Bakiye yüklemesini satış olarak saymak neden yanlış?
Yükleme anında müşteriye henüz bir ürün teslim edilmemiştir; elinde kullanılmayı bekleyen bir alacak vardır. Yüklemeyi satış saymak bir dönemi şişirir, bakiyenin harcandığı dönemi ise olduğundan düşük gösterir.
Ödeme komisyonunu cirodan düşebilir miyim?
Komisyon bir gider kalemidir; net satışı hesaplarken cirodan düşülerek gizlenmemeli, ayrı satır olarak raporlanmalıdır. Böylece hem gerçek satış hacmini hem de ödeme maliyetini ayrı ayrı görürsün.
Dönem kilidi olmayan bir panelle çalışabilir miyim?
Çalışabilirsin ama her dönem sonunda özeti dışa aktarıp kendin arşivlemen gerekir. Aksi hâlde aynı tarih aralığı ileride farklı rakam üretir ve gönderdiğin rakamı kanıtlayamazsın.
Vergi dönemi, işletmenin en çok veri isteyen ama en az hazırlık yapılan anıdır. Oysa doğru kurulmuş bir dönem özeti sadece muhasebecini rahatlatmakla kalmaz; komisyonu, iadeyi ve bakiye yükümlülüğünü görünür kılarak fiyatlandırma kararlarını da düzeltir. Dönem özetinin kalem kalem nasıl çıktığını, kısmi teslimatın ve dönem kilidinin panelde nasıl davrandığını kendi senaryonla test etmek istersen canlı demo üzerinden rapor ekranını açabilir, özellikler bölümünde raporlama başlıklarını ve fiyat planlarını inceleyebilirsin.

