E-Arşiv Faturayı İptal Ettiğini Sanıyorsun Ama Sistem Hâlâ Onu Satış Sayıyor: İptal, İade ve Düzeltme Arasındaki Farkı Bilmeyen Her E-Pin Satıcısının Ödediği Bedel

Çoğu satıcı şunu sanır: müşteri siparişi iptal etti, ben de panelden faturayı iptal ettim, konu kapandı. Oysa e-arşiv dünyasında "iptal" senin panelindeki bir düğme değil, belgenin hukuki durumuna dair bir işlem. Panelinde durum "iptal" yazsa bile, belge alıcıya elektronik olarak iletilmişse ve sistem tarafında iptal kaydı düzgün işlenmemişse o fatura hâlâ senin hasılatın içinde duruyor olabilir. Ay sonunda KDV beyanına o tutar da giriyor ve sen olmayan bir satışın vergisini ödüyorsun.

E-pin, oyun kodu ve dijital ürün satan işletmelerde bu sorun kronikleşiyor, çünkü burada iade sebepleri klasik ticaretten farklı: kod kullanılmadı, kod bölge uyumsuz çıktı, sipariş çift geçti, ödeme başarısız göründü ama bankadan çekildi. Her biri farklı bir muhasebe sonucu doğuruyor. Bu yazıda iptal ile düzeltmenin gerçek farkını, hangi durumda hangisinin kullanılacağını ve kullandığın e-pin scriptinin fatura akışını buna göre nasıl kurgulayacağını konuşacağız.

E-arşiv faturayı gerçekten iptal edebilir misin?

Kısmen. E-arşiv fatura, düzenlendiği anda seri numarası alan ve raporlanan bir belge. Bu yüzden "sil ve yok say" gibi bir hak yok. Yapabileceğin şey, belgeyi iptal statüsüne almak ve bu durumu rapora yansıtmak. İptal edilen belge ortadan kalkmaz; iptal edilmiş haliyle arşivde durmaya devam eder ve istendiğinde ibraz edilir.

Buradaki kritik nokta şu: iptalin geçerli sayılabilmesi için belgenin alıcıya ulaşmamış ya da alıcı tarafından kabul görmemiş olması beklenir. Belge alıcıya iletildiyse ve alıcı bunu kendi kayıtlarına aldıysa, senin tek taraflı iptalin onun defterinde bir boşluk yaratır. O yüzden ticari gerçekliğe uygun yol genelde iptal değil, düzeltme belgesi düzenlemektir.

Bireysel müşteriye yapılan e-pin satışlarında durum biraz daha esnek olur, çünkü alıcı çoğu zaman mükellef değildir. Ama kurumsal alıcıya kesilmiş bir faturada aynı rahatlık yoktur. Panelinde "kurumsal fatura" seçeneği varsa bu ayrımı sistemin de bilmesi gerekir.

Şu meşhur sekiz günlük pencere efsanesi nereden çıktı?

Piyasada dolaşan "e-arşiv faturayı 8 gün içinde iptal edebilirsin" cümlesi, raporlama takvimiyle iptal hakkının karıştırılmasından doğdu. E-arşiv belgeleri periyodik olarak raporlanır ve bu periyoda kadar yapılan değişiklikler teknik olarak daha kolay yansır. Ama bu, "sekizinci günden sonra elin kolun bağlı" demek değil; sonrasında da düzeltme yapılabilir, sadece yöntem değişir.

Pratikte şu ayrımı içselleştir: aynı vergilendirme dönemi içindeki hatalar çoğunlukla iptal veya iade faturasıyla sorunsuz çözülür. Dönem kapandıktan, yani KDV beyannamesi verildikten sonra ortaya çıkan hatalar ise düzeltme beyannamesi gerektirebilir. Bu ikinci senaryo hem zaman hem de mali müşavir emeği demektir.

Bu yüzden e-pin işinde altın kural şudur: iade ve iptal taleplerini asla ayın son gününe biriktirme. Panelin bekleyen iade taleplerini ayrı bir listede göstermiyorsa, o liste kafanda kalır ve kafanda kalan hiçbir şey ay sonunu geçmez.

İade mi iptal mi: e-pin satışında hangisi doğru olan?

Ayrımı belirleyen tek soru: teslim gerçekleşti mi? Dijital ürünlerde teslim, kodun müşteriye görünür hale gelmesidir. Müşteri panelinde kodu gördüyse, e-postayla aldıysa veya API ile çekti ise teslim olmuştur. O noktadan sonra iptal değil iade konuşulur, çünkü satış fiilen doğmuştur ve sonradan geri alınmıştır.

Teslim olmadıysa, yani kod hâlâ senin stoğunda bekliyorsa ve müşteriye hiçbir şey aktarılmadıysa, işlem baştan hiç doğmamış sayılabilir ve iptal yolu açıktır. Bu ayrım o kadar kritiktir ki iyi tasarlanmış bir dijital ürün satış scripti siparişin teslim zamanını ayrı bir alanda tutar ve iade ekranında sana hangi yolun uygun olduğunu söyler.

Uygulamada en çok hata yapılan yer, "müşteri memnun olsun" diye kod teslim edildikten sonra faturanın iptal edilmesi. Bu, kayıtlarında teslim edilmiş bir stok ile iptal edilmiş bir belge bırakır. Stok sayımı ile hasılat birbirini tutmaz ve fark büyüdükçe kimse kaynağını bulamaz.

Otomatik faturalamada en pahalı altı hata hangisi?

Birinci hata: faturayı ödeme alındığı anda değil, sipariş oluştuğu anda kesmek. Ödeme başarısız olursa elinde sahipsiz bir belge kalır. İkinci hata: iade işleminde siparişi veritabanından silmek. Silinen siparişin faturası ortada kalır ve mutabakat çöker. Üçüncü hata: aynı sipariş için tekrar deneme sonucu ikinci belge üretmek; entegratör tarafında çift numara hatası verir.

Dördüncü hata: iptal edilen belgeyi arşivden çıkarmak. Beşinci hata: belge numarası ile sipariş numarasını ilişkilendirmemek, yani panelde "bu siparişin faturası hangisi" sorusuna cevap olmaması. Altıncı ve en sinsi hata: kısmi iadeyi tam iade gibi işlemek. Üç kodluk siparişin bir kodu iade edildiğinde tamamını iptal edersen iki kodun hasılatını da silmiş olursun.

Bu altı hatanın hepsi yazılım tarafında çözülebilir hatalar. Bu yüzden bir e-pin satış yazılımı seçerken "fatura entegrasyonu var mı" sorusu yetersiz; doğru soru "iade, kısmi iade ve iptal akışlarını ayrı ayrı yönetiyor mu" sorusudur.

GİB tarafına düşen bir iptal talebi neden reddedilir?

Reddin en yaygın sebebi, iptal talebinin belgenin fiili durumuyla çelişmesi. Alıcı belgeyi kabul etmiş, hatta kendi kayıtlarına almışsa, tek taraflı iptal onaylanmaz. İkinci sebep zamanlama: dönem kapanmış ve beyan verilmişse artık iptal değil düzeltme mekanizması işler.

Üçüncü sebep, gerekçenin zayıflığı. "Yanlışlıkla kesildi" ifadesi tek başına yeterli olmayabilir; hangi sipariş, hangi tutar, hangi tarih, neden yanlış — bunların kaydı olmalı. İşte burada panelinin tuttuğu iade gerekçesi alanı kağıt üzerinde küçük ama denetimde büyük bir detaydır. Gerekçesi yazılı olan her iade, savunulabilir bir iadedir.

Dördüncü sebep teknik: entegratör ile senin kayıtlarının uyuşmaması. Panelde iptal görünüp entegratörde aktif duran belgeler, ay sonu raporlarında hayalet satış olarak karşına çıkar. Bu yüzden entegratör raporunu ayda bir panel raporuyla karşılaştırmak zorunlu rutin olmalı.

Scriptinin fatura akışını iptale hazır nasıl kurarsın?

Beş maddeye indirebilirim. Bir: her siparişte fatura numarası, fatura tarihi ve belge durumu ayrı alanlarda tutulsun. İki: iade işlemi siparişi silmesin, siparişin altına negatif bir hareket açsın. Üç: kısmi iade desteklensin, satır bazında miktar girilebilsin. Dört: teslim zamanı damgası olsun, böylece iptal mi iade mi kararını sistem versin. Beş: entegratör yanıtları log'lansın, hata durumunda tekrar deneme aynı belgeyi ikilemesin.

Pinova tarafında bu akış tam olarak bu mantıkla kurulu: sipariş, teslim ve belge üç ayrı katman olarak duruyor ve biri değiştiğinde diğerinin izi kaybolmuyor. Yani "iptal ettim ama hasılatta duruyor" tablosu oluşmuyor. Sistemin fatura ve iade tarafındaki yeteneklerini /#ozellikler bölümünden, hangi pakette ne olduğunu satın alma sayfası üzerinden inceleyebilirsin.

Doğru kurulmuş bir e-pin satış scripti ile ay sonu kapanışı, üç sayının birbirini tutup tutmadığını görmekten ibarettir. Yanlış kurulmuşsa aynı iş, yüzlerce siparişi tek tek açıp kontrol etmek demektir. Aradaki fark sadece zaman değil, ödediğin fazla verginin miktarıdır.

Faturayla ilgili sorunların çoğu, aslında yazılımın sipariş ve teslim kaydını nasıl tuttuğuyla ilgili sorunlar. Belgenin arkasındaki veriyi doğru tutan bir sistemde iptal de iade de tek tıkla ve iz bırakarak gerçekleşir. Kendi iş akışında nasıl duracağını görmek için canlı demo üzerinden bir sipariş oluştur, kodu teslim et, sonra kısmi iade uygula; hangi kayıtların değiştiğini ve hangilerinin yerinde kaldığını izlediğinde neden bu ayrımın bu kadar önemli olduğunu somut olarak göreceksin.