E-pin Scriptini Muhasebe Yazılımına Bağlamayan Herkes Aynı Hatayı Yapıyor: Ay Sonunu 4 Saatten 4 Dakikaya İndiren Aktarım Sistemini İfşa Ediyoruz

Çoğu e-pin satıcısı şunu sanır: "Satışlar panelde duruyor, ay sonunda Excel'e atarım, muhasebeci gerisini halleder." Kulağa mantıklı geliyor, değil mi? Ta ki ilk ciddi ay sonunu kapatana kadar. Çünkü panelden dökülen ham liste ile muhasebecinin defterine girecek kayıt aynı şey değil. Birinde 2.400 satırlık sipariş listesi var, diğerinde ise tarih, belge numarası, KDV oranı, tahsilat kanalı ve iade eşleşmesi olan düzenli bir yevmiye ihtiyacı var. Arada duran boşluğu her ay senin mesain kapatıyor.

İşin ilginç tarafı şu: bu boşluk teknik bir sınır değil, kurgu eksikliği. Doğru kurulmuş bir e-pin satış scripti zaten muhasebenin istediği her alanı üretiyor; sorun o alanların hangi başlık altında, hangi formatta ve hangi zamanlamayla dışarı çıktığında yaşanıyor. Bu yazıda, dijital ürün satış yazılımı ile muhasebe programı arasındaki köprüyü bir kere kurup unutmanın yolunu adım adım açacağız. Kimsenin blogda anlatmadığı kısım da burada: kırılma noktaları satışta değil, iade ve komisyon satırlarında.

"Excel yeter" diyenler neden her ay aynı yerde tıkanıyor?

Excel bir aktarım aracı değil, bir ara durak. Panelden aldığın dökümü açtığın anda üç şey olur: sütun başlıkları muhasebe programının beklediğiyle uyuşmaz, tarih formatı bozulur, sipariş numaraları başındaki sıfırları kaybeder. Bunları elle düzeltirsin, dosyayı yüklersin, program üç satırı reddeder, sen o üç satırı avlarsın. Kırk dakika gitti. Bir sonraki ay aynı film tekrar oynar, çünkü düzelttiğin şey veri değil, o ayın dosyasıydı.

Asıl maliyet zaman da değil aslında. Elle dokunulan her kayıt, denetlenebilirliğini kaybeder. Muhasebeci sana "12 Mart'taki 380 TL nereden geldi?" diye sorduğunda, elinde panele geri dönüp izini sürebileceğin bir referans numarası yoksa tahmin yürütmeye başlarsın. Oysa e-pin yazılımı tarafında her siparişin zaten benzersiz bir kimliği, bir tahsilat kaydı ve bir zaman damgası var. Aktarımı doğru kurmak, bu kimliği muhasebe kaydının içine taşımak demek. O tek alan sayesinde her rakam kendi kaynağına geri bağlanır ve mutabakat tartışma konusu olmaktan çıkar.

Muhasebeci senden ne istiyor, script sana ne veriyor?

Bu iki listeyi yan yana koymadan hiçbir aktarım düzgün kurulamaz. Muhasebe tarafı belge odaklı düşünür: her hareketin bir tarihi, bir tutarı, bir vergi oranı ve bir karşı hesabı olmalı. Script tarafı ise işlem odaklı düşünür: sipariş, stok düşümü, bakiye hareketi, teslimat kaydı. İkisini eşlemek, teknik bir iş değil muhasebe dilini öğrenme işidir. Aşağıdaki tablo, sahada en çok sorun çıkaran eşlemeleri ve her birinde atlanan detayı gösteriyor.

Aktarımın gizli kırılma noktası: iade, kısmi iade ve bakiye

Satış satırını aktarmak kolay kısımdır. İşler iade geldiğinde karışır. Diyelim müşteri 150 TL'lik bir kod aldı, kod çalışmadı, sen iade ettin. Panelde bu tek tıkla "iptal" oldu. Muhasebe tarafında ise iki ayrı hareket gerekiyor: satışın ters kaydı ve tahsilatın iadesi. Eğer aktarım sadece "iptal olan siparişi listeden çıkarıyorsa", geçmiş dönem rakamları sessizce değişir ve kapanmış bir ayın cirosu bugün farklı görünmeye başlar. Denetimde bunu açıklamak gerçekten zor.

Kısmi iade daha da sinsi. On adetlik bir paketten üç adet teslim edilemediyse, tutarın tamamı değil bir kısmı geri döner. Bu durumda iade satırının orijinal sipariş numarasını taşıması ve kendi belge numarasına sahip olması gerekir. Bakiyeden yapılan satışlar ise üçüncü tuzak: müşteri cüzdanına para yüklediğinde bu bir satış değil, avanstır. Satış ancak o bakiye bir ürüne harcandığında doğar. Bunu ayırmayan bir kurgu, cironun bir kısmını iki kez sayar. Dijital ürün satış scripti tarafında bakiye hareketlerinin ayrı bir defterde tutulması, bu karışıklığı baştan bitiriyor.

Manuel dosya mı, otomatik köprü mü? Karar tablosu

Herkesin otomatik entegrasyona ihtiyacı yok. Ayda 60 sipariş alıyorsan, düzgün başlıklandırılmış bir CSV dökümü fazlasıyla yeterlidir; önemli olan o dökümün her ay aynı şablonda çıkması. Ama gün içinde yüzlerce işlem dönüyorsa, insan eli devreden çıkmalı. Kırılma noktası genelde günlük 50 işlem civarında başlıyor: bu eşiğin üstünde manuel kontrol, hatayı azaltmak yerine geciktiriyor.

Ara bir yol da var ve çoğu işletme için en sağlıklısı bu: gün sonu özet aktarımı. Her gece script, o günün satış, iade, komisyon ve tahsilat toplamlarını tek bir dosyada üretir; muhasebe programı bunu tek hareket olarak okur. Satır sayısı yüzde doksan azalır, denetim izi bozulmaz, çünkü özet satırının arkasındaki detay panelde duruyor ve referans numarasıyla erişilebilir durumda kalıyor.

Kur farkı ve komisyon: tek satırda saklanan üç ayrı kalem

Dijital ürün tedarikinde alış çoğu zaman dövizle, satış ise Türk Lirası ile yapılıyor. Panelde "kâr" olarak gördüğün rakam, muhasebe gözüyle üç kalemin toplamıdır: ürün maliyeti, kur farkı ve ödeme kanalı komisyonu. Bunları tek satırda birleştirip aktarırsan, aylar sonra "neden marjım düştü?" sorusuna cevap veremezsin, çünkü marjı düşüren şeyin fiyat mı kur mu komisyon mu olduğunu ayıramazsın.

Doğru kurgu şöyle işler: satış satırı her zaman brüt tutarla gider, komisyon ayrı bir gider kaydı olur, kur farkı ise dönem sonunda ayrı bir hesapta toplanır. Böylece cironu olduğu gibi görürsün, giderleri kalem kalem izlersin. Bu ayrımı e-pin satış yazılımı tarafında sipariş kaydına eklenen üç sayısal alanla yapmak yeterli; gerisi aktarım şablonunun işi. Pinova'nın raporlama katmanı bu üç kalemi baştan ayrı tuttuğu için, dışarı verilen dosya muhasebecinin elinde ek işlem gerektirmiyor. Ayrıntıları özellikler bölümünde görebilirsin.

Aktarımı kurduktan sonra ay sonu gerçekten nasıl görünüyor?

Düzgün kurulmuş bir köprüde ay sonu kapanışı bir kontrol işine dönüşür. Üç rakama bakarsın: panel cirosu, banka girişi ve muhasebe kaydı. Üçü tutuyorsa kapanış bitmiştir. Tutmuyorsa fark tek bir kalemde toplanmıştır ve onu bulmak dakikalar sürer. Aşağıdaki kontrol listesini ilk kurulumdan sonra bir kez, ardından her çeyrekte bir tekrar çalıştırman yeterli.

Aktarımın ne kadar kolaylaştığını anlamanın en hızlı yolu, raporların nasıl üretildiğini kendi gözünle görmek. Fiyatlandırmayı fiyat bölümünden inceleyebilir, satış ve iade defterlerinin nasıl ayrıştığını canlı demo üzerinde tek tek gezerek test edebilirsin; ay sonunu dakikalara indiren şey karmaşık bir entegrasyon değil, baştan doğru kurulmuş bir veri düzeni.