Dijital ürün satan çoğu işletme sahibi fatura konusunu şöyle düşünür: “Ben kod satıyorum, kargo yok, elden teslim yok, kimse fatura istemiyor, o zaman sorun da yok.” Bu cümlenin sonunda genelde bir vergi dairesi yazısı ya da bir ödeme kuruluşunun “belgelendirilmiş satış oranın düşük” uyarısı bekler. Faturanın müşteriden gelen bir talep olduğunu sanmak, en pahalı yanlış varsayımdır; fatura müşteri için değil, satışın kendisi için kesilir ve kesilmediğinde ortaya çıkan şey sadece ceza değil, iş modelinin bankacılık ve ödeme tarafında kırılganlaşmasıdır.
İkinci yanlış varsayım ise şu: “Muhasebecim hallediyor.” Muhasebeci kendisine ulaşan veriyi işler. Ona aylık 4.000 satırlık bir ekstre gönderirsen, o ekstre üzerinden fatura üretmesi hem imkânsız hem de hukuken senin sorumluluğundadır. Burada asıl belirleyici olan, satışın gerçekleştiği yerde, yani e-pin scriptinin içinde faturanın doğru anda ve doğru alanlarla oluşmasıdır. Bu yazıda hangi belge türünün seni ilgilendirdiğini, entegrasyonu hangi yoldan kuracağını, iade-iptalde nerede hata yapıldığını ve dijital ürün satış yazılımının fatura modülünde neyin bulunması gerektiğini sırayla ele alıyorum. Rakamsal eşikler ve tebliğ tarihleri zaman içinde güncellendiği için son durumu her zaman mali müşavirinle doğrula; buradaki amaç sistem kurmayı öğretmek.
Dijital ürün satarken fatura gerçekten zorunlu mu?
Kısa cevap: evet. Sattığın şeyin fiziksel olup olmaması belge yükümlülüğünü değiştirmez; bir bedel karşılığı mal veya hizmet teslim ediyorsan belge düzenlemek zorundasın. Dijital ürünlerde tek fark, teslim anının tespiti ve KDV'nin hangi tarih üzerinden hesaplandığıdır. Şahıs işletmesi de olsan, limited şirket de olsan sonuç aynı: satış varsa belge var. “Hobiden yapıyorum” savunması, düzenli ve süreklilik arz eden satışlarda geçerli değildir; süreklilik tespit edildiğinde geçmişe dönük değerlendirme yapılır.
İkinci mesele belgenin kime kesileceğidir. Alıcı nihai tüketiciyse e-Arşiv fatura, alıcı e-Fatura mükellefi bir şirketse sistemler arası e-Fatura devreye girer. Bu ayrımı satış anında yapabilmen gerekir; yani müşteriden VKN/TCKN alıp mükellefiyet durumunu kontrol eden bir akışa ihtiyacın var. Bunu elle yapmaya kalkarsan iki şey olur: ya yanlış belge türü keser ve reddedilir, ya da hiç kesmez ve açık kalırsın. İşte bu yüzden fatura mantığının, satış akışının dışında değil e-pin satış scriptinin içinde yaşaması gerekir.
e-Arşiv, e-Fatura, e-İrsaliye: hangisi seni ilgilendiriyor?
Karışıklığın büyük kısmı isimlerden çıkıyor. e-Fatura, mükellefler arasında GİB'in kapalı sistemi üzerinden dolaşan, alıcının onay/ret verebildiği belgedir. e-Arşiv fatura ise mükellef olmayan kişilere, yani son kullanıcıya kesilen ve elektronik ortamda iletilip raporlanan belgedir. Dijital ürün satıcılarının ezici çoğunluğu için asıl kalem e-Arşiv faturadır; kurumsal müşteriye toptan e-pin satıyorsan e-Fatura tarafı da açılır. e-İrsaliye fiziksel sevkiyatla ilgilidir, dijital teslimatta seni ilgilendirmez.
Bunun yanında iki ayrıntı var. Birincisi, e-ticaret üzerinden yapılan satışlarda tutar eşiğine bakılmaksızın e-Arşiv fatura düzenleme beklentisi vardır; “küçük tutarlar için gerek yok” yaklaşımı burada işlemez. İkincisi, yurt dışına satış yapıyorsan ihracat ve döviz kuru tarafı ayrı bir başlıktır ve faturada kur, tarih ve ülke bilgilerinin doğru işlenmesi gerekir. Scriptin çok para birimli satış yapıyorsa, faturaya giden tutarın hangi kurla TL'ye çevrildiğini kayıt altında tutması şarttır; aksi halde ay sonunda muhasebe ile aradaki kuruş farkları toplanıp anlamsız bir sapmaya dönüşür.
| Yöntem | Nasıl çalışır | Kime uygun | Zayıf tarafı |
|---|---|---|---|
| GİB Portal | Faturalar web arayüzünden elle girilir | Ayda birkaç fatura kesen küçük hacim | Otomasyon yok, hacim arttıkça imkânsız |
| Özel entegratör (API) | Script entegratörün API'sine fatura gönderir | Günlük onlarca/yüzlerce sipariş | Aylık/kontenjan bazlı ücret |
| Doğrudan entegrasyon | Kendi sunucun GİB'e bağlanır | Çok yüksek hacim, teknik ekibi olan | Yüksek kurulum ve sürekli uyum yükü |
| Muhasebe yazılımı köprüsü | Siparişler muhasebeye akar, fatura oradan keser | Ön muhasebesi kurulu işletme | Gecikme ve eşleme hataları riski |
Özel entegratör mü, doğrudan GİB mi? Hangisi scriptine oturur?
Pratikte dijital ürün satıcılarının %90'ı için doğru cevap özel entegratördür. Sebep basit: GİB'e doğrudan bağlanmak, şemayı, imzalama altyapısını, raporlama takvimini ve versiyon değişikliklerini kendi başına takip etmek anlamına gelir. Bu, bir e-pin işletmesinin çözmesi gereken bir problem değil. Entegratör seçerken ise şu dört soruyu sor: REST API sunuyor mu, test (sandbox) ortamı var mı, iptal/itiraz uçları açık mı, aylık kontenjan aşımında ne oluyor?
Scriptin tarafında bakılacak nokta ise bağlantının nerede durduğudur. Fatura entegrasyonu ürün kodunun içine gömülmüşse her entegratör değişiminde kod değiştirmek zorunda kalırsın. Doğru mimari, fatura gönderimini tek bir soyut katmanda tutar: sipariş kapanır, standart bir fatura nesnesi üretilir, hangi sağlayıcıya gideceği ayarlardan seçilir. Böylece entegratörünü değiştirdiğinde geceyi kod düzeltmekle geçirmezsin. Bu tür yapısal ayrımların hangi modüllerde nasıl kurulduğunu özellikler bölümünde görebilirsin.
Dijital satışta fatura hatalarının kaynağı
- Eksik/yanlış alıcı bilgisi 40%
- İade ve iptalin işlenmemesi 30%
- Fatura zamanının kaçması 20%
- Entegratör iletim hatası 10%
Faturayı hangi saniyede kesmelisin?
Dijital üründe en çok tartışılan konu budur. Sipariş oluştuğunda mı, ödeme onaylandığında mı, teslimat yapıldığında mı? Uygulamada en sağlam tetikleyici ödeme onayının düştüğü andır; çünkü bedelin tahsil edildiği an ile teslimatın yapıldığı an dijital üründe birkaç saniye farkla gerçekleşir. Sepet oluştuğunda fatura kesmek büyük hata olur: tamamlanmayan her sepet için iptal edilmesi gereken bir belge üretirsin ve ay sonunda iptal yığınıyla uğraşırsın.
Burada kritik ayrıntı kuyruk mantığıdır. Entegratör API'si o anda yanıt vermiyorsa satış durmamalı; fatura kaydı kuyruğa alınıp tekrar denenmelidir. Ayrıca her fatura girişiminin idempotent olması gerekir: aynı sipariş için ikinci deneme yeni bir fatura değil, aynı faturanın durumunu sorgulamalı. Bu iki kural yoksa bir API kesintisi sonrası aynı müşteriye üç fatura kesilmiş olduğunu ancak muhasebeci fark eder ve düzeltmesi günler alır. Kuyruk + idempotency, fatura modülünün olmazsa olmaz ikilisidir.
Canlıya geçmeden önce mutlaka şunları test et: başarılı fatura, API zaman aşımı sonrası tekrar deneme ve kısmi iade sonrası iptal. Bu üçü çalışıyorsa modül gerçekten hazırdır.
İade ve iptalde işler nerede çığırından çıkıyor?
Dijital üründe iade tartışmalıdır: kod teslim edildikten sonra cayma hakkının kapsamı daralır, ancak teslim edilmemiş ya da çalışmayan bir ürün için mutlaka bir iade akışın olmalı. Sorun şurada başlıyor: satıcı parayı iade ediyor, faturayı iptal etmiyor. Böylece kayıtlarda tahsil edilmiş görünen ama kasada olmayan bir tutar birikiyor ve KDV fazladan ödeniyor. Yıl sonunda “neden bu kadar vergi çıktı?” sorusunun cevabı genelde tam olarak burasıdır.
Doğru akış şu: iade talebi panelde kayıt altına alınır, iade onaylanınca ödeme tarafında para geri döner, aynı işlem fatura tarafında iptal ya da düzeltme belgesi tetikler ve sipariş durumu “iade edildi” olarak kilitlenir. Kısmi iadelerde ise tutar bazlı düzeltme gerekir. Bu zincirin tamamı otomatik olmalı; çünkü elle yapıldığında insan mutlaka son adımı atlar. Bir e-pin yazılımı değerlendirirken “iade ediyor mu?” diye değil, “iade fatura tarafını da kapatıyor mu?” diye sor.
Fatura modülünde bulunması gereken yedi şey
Somutlaştıralım. Birincisi, sipariş formunda fatura tipi seçimi (bireysel/kurumsal) ve buna göre değişen zorunlu alanlar. İkincisi, VKN/TCKN format doğrulaması ve mükellefiyet sorgusu. Üçüncüsü, unvan-adres-vergi dairesi alanlarının kayıtlı müşteri profilinde saklanması, böylece tekrar alan müşteri her seferinde aynı bilgiyi yazmaz. Dördüncüsü, KDV oranının ürün bazında tanımlanabilmesi; tüm katalogda tek oran varsaymak yanlış kayda yol açar.
Beşincisi, faturanın müşteri paneline PDF olarak düşmesi ve e-posta ile iletilmesi; bu tek başına destek talebi sayını ciddi biçimde azaltır. Altıncısı, yönetici panelinde “faturası kesilmemiş siparişler” listesi; bu liste her gün sıfırlanabiliyorsa sistemin sağlıklıdır. Yedincisi, muhasebe için dönemsel dışa aktarım: seçilen tarih aralığındaki tüm belgeleri tek dosyada verebilmek. Bu yedi maddeyi sağlayan bir yapı, ayda 3.000 siparişte de 30 siparişte de aynı şekilde çalışır. Hangi paketin hangi modülleri kapsadığını fiyat tablosundan karşılaştırıp kurulum adımına geçebilirsin.
| Kontrol adımı | Sorumlu | Tamam sayılma ölçütü |
|---|---|---|
| Mükellefiyet ve belge türü tespiti | Mali müşavir | e-Arşiv/e-Fatura kapsamı yazılı netleşti |
| Entegratör sözleşmesi | İşletme sahibi | API anahtarı ve sandbox erişimi alındı |
| Seri ve sıra numarası tanımı | Muhasebe + teknik | Test faturası doğru seri ile düştü |
| Alıcı alanları doğrulaması | Teknik | Hatalı VKN girişi formda engelleniyor |
| Fatura tetikleyicisi | Teknik | Ödeme onayında otomatik oluşuyor |
| Kuyruk ve tekrar deneme | Teknik | API kapalıyken sipariş kapanıyor, fatura sonra gidiyor |
| İade/iptal zinciri | Teknik + muhasebe | Para iadesi belge iptalini tetikliyor |
| Müşteriye iletim | Teknik | PDF panelde ve e-postada mevcut |
| Aylık mutabakat | Mali müşavir | Belge toplamı ile tahsilat toplamı örtüşüyor |
Fatura tarafını kapatmadan ölçeklenmez
Satışın hızlanması, belgesiz satışın da hızlanması demek olmasın. Pinova, siparişten faturaya kadar zinciri tek panelde kuran dijital ürün satış yönetim yazılımıdır.
Küçük tutarlı dijital satışlar için fatura kesmesem olur mu?
Olmaz. E-ticaret kanalıyla yapılan satışlarda tutar küçüklüğü belge yükümlülüğünü kaldırmaz. Güncel eşik ve tebliğ durumunu mali müşavirinle doğrulaman en doğrusu.
Özel entegratör şart mı, portalden elle giremez miyim?
Ayda birkaç fatura kesiyorsan portal yeter. Günlük onlarca sipariş varsa elle giriş sürdürülemez; API'li entegratör ve otomatik tetikleyici gerekir.
Kod teslim edildikten sonra iade talebinde ne yapmalıyım?
İade politikanı yasal metinlerinde net yaz. İade onaylandığında hem ödeme geri döner hem de fatura iptal ya da düzeltme belgesiyle kapatılmalıdır; ikisi birlikte yapılmazsa fazladan KDV ödersin.
Yurt dışına yaptığım satışlarda kur nasıl işlenir?
Satış anındaki kur, hangi kaynaktan alındığı ve TL karşılığı sipariş kaydında saklanmalıdır. Belgeye giden tutar bu kayıtla aynı olmalı ki ay sonu mutabakatta sapma çıkmasın.
Fatura tarafı, büyümenin önündeki en sessiz frendir: sen pazarlamaya bütçe ayırırken arkada belgesiz satış yığını birikir ve bir gün ölçeklenmenin bedeli olarak önüne düşer. Oysa doğru tetikleyici, kuyruk mantığı ve iade zinciri bir kez kurulduğunda bu iş tamamen görünmez hâle gelir. Zincirin uçtan uca nasıl çalıştığını görmek için canlı demo üzerinden bir test siparişi oluşturup fatura kaydının ve müşteri panelindeki belgenin nasıl düştüğüne kendi gözünle bak; kararını ondan sonra ver.