E-Pin İşletmelerinde Muhasebe Kayıtlarının Düzenli Tutulması

Bir e-pin ve dijital ürün satış işletmesinde gün içinde onlarca, bazen yüzlerce işlem gerçekleşir: kod satışı, bayi bakiye yüklemesi, tedarikçi faturası, iade, komisyon. Her biri küçük ama toplamı işletmenin defterini oluşturur. Peki bu kadar hızlı akan veriyi kim, ne zaman, hangi kalemde kayıt altına alıyor?

E-Pin Satışında Muhasebe Neden Bu Kadar Çabuk Karmaşıklaşır?

Klasik bir e-ticaret işletmesinde günde birkaç düzine sipariş olur ve her siparişin tutarı, kargo maliyeti, komisyonu ayrı ayrı izlenebilir. E-pin işinde ise işlem hacmi çok daha yüksektir; tek bir kullanıcı aynı gün içinde 5-6 farklı ürün satın alabilir, bir bayi saatte onlarca kod çekebilir. İşlem başına tutar küçük olduğu için "önemsiz" görünür, ama yıl sonunda binlerce satırın toplamı beyannameye giden rakamı oluşturur.

Karmaşıklığı artıran asıl unsur, paranın üç farklı katmanda hareket etmesidir:

• Müşteriden gelen tahsilat (PayTR, Shopier, havale/EFT)
• Tedarikçiye (Turkpin, Pinabi gibi) ödenen maliyet
• Bayiye tanınan cari bakiye ve ondan düşülen komisyon farkı

Bu üç hareket aynı anda, farklı hızlarda ve farklı sistemlerde gerçekleştiği için elle takip eden bir işletme kısa sürede hangi tahsilatın hangi maliyetle eşleştiğini kaybeder.

İşin bir de mevsimsellik boyutu var. Oyun içi kod ve dijital ürün satışları özellikle indirim dönemlerinde (yeni sezon başlangıçları, özel kampanya günleri) normalin birkaç katına çıkabilir. Bu ani hacim artışında, ödeme sağlayıcı tarafında oluşan komisyon kesintileri, kur farkları (döviz bazlı tedarik yapan işletmelerde) ve iade oranındaki değişimler de tabloya eklenir. Kağıt üzerinde "basit bir satış işlemi" olarak görünen her kod teslimi, aslında arka planda beş altı farklı muhasebe kalemini aynı anda tetikler. Bu kalemleri gün içinde tek tek elle işleyen bir işletme, ayın sonunda hangi günün kârlı hangi günün zararına satış yaptığını bile net göremez hale gelir.

Her Satış Gerçekten Bir Fatura Kaydı Doğurur mu?

Türk vergi mevzuatında dijital kod satışı da diğer mal/hizmet satışları gibi belgelendirilmesi gereken bir işlemdir. Bireysel müşteriye yapılan satışlarda çoğunlukla e-arşiv fatura veya perakende satış fişi düzenlenir; bayiye yapılan toptan satışlarda ise e-fatura zorunluluğu devreye girebilir. Sorun, hangi işlemin hangi belge türünü gerektirdiğinin manuel takipte sık sık karıştırılmasıdır.

Ayrıca KDV oranı ürün tipine göre değişebilir ve tedarikçiden alınan faturadaki KDV ile satış faturasındaki KDV'nin doğru şekilde beyan edilmesi gerekir. Bu eşleşme yapılmazsa iki sonuçtan biri ortaya çıkar: ya gereğinden fazla vergi ödenir ya da eksik beyan riski doğar. İkisi de işletmeyi zor durumda bırakır.

Otomatik sistemlerde her satış anında bir işlem kaydı (transaction log) oluşur; bu kayıt tutar, tarih, ürün, ödeme yöntemi ve müşteri bilgisini birlikte tutar. Muhasebeci bu kaydı doğrudan fatura kesim sürecine aktarabilir, ayrıca elle veri girmesi gerekmez.

Bir de sıkça atlanan bir ayrım var: iptal edilen veya iade edilen bir kod satışının muhasebe kaydı ne olacak? Fatura zaten kesildiyse iade faturası veya iptal belgesi düzenlenmesi gerekir; kesilmediyse işlem hiç kayda girmemiş gibi silinmelidir. Elle tutulan tablolarda iade satırı genellikle basitçe siliniyor, oysa bu hem stok hem de tedarikçi maliyeti tarafında bir iz bırakmalı. Aksi halde tedarikçiden alınan kod, sistemde "satılmış" görünmeye devam eder ve dönem sonu mutabakatında fazladan bir maliyet olarak defterde kalır.

Tedarikçi Faturaları Satış Kayıtlarıyla Nasıl Eşleşmeli?

Turkpin veya Pinabi gibi tedarikçilerden alınan kodların maliyeti, genellikle dönemsel (haftalık veya aylık) toplu fatura ile gelir. Ama satışlar günlük, hatta dakikalık olarak gerçekleşir. Bu zaman farkı, "hangi satışın maliyeti hangi faturaya ait" sorusunu doğurur.

Elle takip eden işletmeler genelde iki yoldan birini seçer: ya her satışı tek tek tedarikçi ekstresiyle eşleştirmeye çalışır (zaman kaybı ve hata riski yüksektir) ya da dönem sonunda toplam satış ile toplam tedarikçi faturasını kabaca kıyaslar (marjın nereden eridiğini göremez). İkinci yöntem özellikle kâr marjı düşük ürünlerde (oyun içi para, dijital kod) hangi ürün grubunun zarar ettiğini gizler.

Doğru yaklaşım, her satışın API üzerinden çekildiği anda tedarikçi maliyetinin de sisteme otomatik işlenmesidir. Böylece dönem sonunda tek tuşla "bu ayki toplam maliyet" ile "tedarikçiye ödenen fatura tutarı" karşılaştırılabilir; fark varsa hemen görülür.

Birden fazla tedarikçiyle çalışan işletmelerde bu eşleştirme bir kat daha zorlaşır. Aynı ürün grubu (örneğin oyun içi para) hem Turkpin'den hem Pinabi'den farklı fiyatlarla temin ediliyorsa, hangi satışın hangi tedarikçiden gelen kodla teslim edildiğinin ayrı ayrı işaretlenmesi gerekir. Aksi halde ortalama maliyet üzerinden kabaca bir kâr hesabı yapılır ve gerçek marj gizlenir. Kod bazlı izleme yapan bir sistemde her teslimatın hangi tedarikçi partisinden geldiği baştan sisteme kaydedildiği için, dönem sonunda tedarikçi bazlı kârlılık raporu da otomatik çıkar.

Bayi Cüzdanları Muhasebe Tablosunda Nereye Yazılır?

Çok seviyeli bayi sistemi çalıştıran bir e-pin işletmesinde para, müşteriden gelmeden önce bazen zaten bayinin cüzdanında bekliyordur. Bayi önceden bakiye yükler, sonra bu bakiyeden satış yaptıkça düşülür. Bu model klasik "satış anında tahsilat" mantığından farklıdır ve muhasebede cari hesap (avans/emanet) mantığıyla ele alınmalıdır.

Burada üç ayrı kayıt türü ortaya çıkar:

• Bayinin cüzdana yaptığı yükleme (işletme için bir tür avans tahsilatı)
• Bayinin cüzdanından yaptığı her satış (bakiyeden düşüş, gelir kaydı değil, iç transfer)
• Bayiye tanınan komisyon veya iskonto farkı (gerçek gelir/gider kalemi)

Bu üçünü birbirine karıştırmak, aslında henüz gerçekleşmemiş bir satışı erken gelir olarak yazmaya veya tam tersi gerçek geliri cüzdan hareketi sanıp gözden kaçırmaya yol açabilir. Cüzdan bakiyesi otomatik ve tarihli tutulmadığında, dönem sonunda "bayilerde toplam ne kadar bakiye var" sorusunun cevabı bile net değildir — oysa bu rakam bilanço açısından işletmenin bir yükümlülüğüdür.

Çok seviyeli bayi yapısında bir katman daha eklenir: alt bayilerin üst bayiye bağlı olduğu, komisyonun kademeli paylaşıldığı senaryolar. Bu durumda tek bir satışın geliri, aslında iki veya üç farklı hesap arasında bölüşülür. Kim, ne kadar komisyon aldı, ana işletmeye net ne kaldı — bu sorunun cevabı elle tutulan bir defterde saatler içinde bile netleşmeyebilir. Sistem üzerinden otomatik hesaplanan komisyon dağılımı ise her satış anında kesinleşir ve her seviyenin defterine doğru tutarla yansır.

Excel Takibi Hangi Ciroda Çökmeye Başlıyor?

Küçük ölçekte, günde 10-15 satış yapan bir işletme için Excel tablosu yeterli görünebilir. Ancak işlem sayısı günde 50'yi, bayi sayısı 5-10'u geçtiğinde tablo büyümeye başlar; formüller yavaşlar, sekmeler çoğalır, aynı veriyi iki kişi farklı şekilde günceller. Bu noktadan sonra Excel bir takip aracı olmaktan çıkıp bir risk kaynağına dönüşür.

En sık karşılaşılan sorunlar şunlardır:

• Aynı satışın yanlışlıkla iki kez tabloya girilmesi (çift kayıt)
• Formül hatası nedeniyle toplam tutarın yanlış hesaplanması
• Dosyanın farklı sürümlerinin farklı kişilerde kalması ve hangisinin "güncel" olduğunun bilinmemesi
• Sistem çöktüğünde veya dosya bozulduğunda geriye dönük kaydın olmaması

Otomatik teslimat yapan bir yazılımda ise her işlem, gerçekleştiği anda sistemin kendi veritabanına yazılır; insan eliyle girilmediği için çift kayıt veya unutma riski neredeyse sıfırlanır. Pinova gibi bir altyapıda işlem geçmişi zaten sistemin doğal bir parçasıdır — ayrıca bir "muhasebe tablosu" tutmaya gerek kalmaz, mevcut kayıtlar dışa aktarılır.

Excel'in asıl zayıflığı hız değil, güvenilirlik eksikliğidir. Bir tablo dosyası kimin ne zaman değiştirdiğini genelde göstermez; bir satır silinirse geri gelmez, formül yanlışlıkla üzerine yazılırsa fark edilmesi haftalar sürebilir. Oysa muhasebe kaydının temel şartı değiştirilemezlik ve izlenebilirliktir — hangi kaydın ne zaman oluştuğu, kimin işlem yaptığı belli olmalıdır. Bu nedenle büyüyen bir e-pin işletmesi için soru "Excel mi kullanayım otomasyon mu" değil, "ne zaman geçmem gerekiyor" sorusudur; genellikle cevap, ilk denetim veya ilk büyük mutabakat sorunuyla karşılaşmadan önce olmalıdır.

Bir Vergi İncelemesinde İlk Sorulan Kayıt Hangisi Olur?

Vergi incelemesi veya denetim sürecinde ilk istenen belgeler genellikle satış faturaları, tedarikçi faturaları ve bunların birbiriyle tutarlılığıdır. İnceleme elemanı, beyan edilen ciro ile fiilen gerçekleşen işlem hacmi arasında fark olup olmadığını görmek ister. E-pin işinde bu karşılaştırma özellikle hassastır, çünkü işlem sayısı yüksek ve ortalama tutar düşüktür — küçük tutarsızlıklar toplamda büyük farklara dönüşebilir.

Denetime hazır bir işletmenin elinde şu kayıtlar eksiksiz ve tarihli olmalıdır:

• Her satışın zaman damgalı işlem kaydı (kim, ne zaman, ne kadar, hangi ödeme yöntemiyle)
• Tedarikçiden alınan maliyet faturalarının satışlarla eşleşen dökümü
• Bayi cüzdan hareketlerinin ayrı ve izlenebilir dökümü
• İade ve iptal işlemlerinin gerekçeli kaydı

Bu kayıtlar sistem tarafından otomatik ve değiştirilemez şekilde tutulduğunda, denetim süreci günler yerine saatler sürer; çünkü muhasebeci veya mali müşavir tek bir rapor talep edip ilgili dönemi dışa aktarabilir. Kayıtlar dağınık dosyalarda ise aynı süreç haftalar alabilir ve eksik belge riski doğar.

Burada gözden kaçan bir başka nokta, kayıt saklama süresidir. Türk vergi mevzuatına göre ticari defter ve belgeler belirli bir süre (genellikle beş yıl) saklanmak zorundadır. Elle tutulan tablolar bilgisayar değişimi, disk arızası veya basitçe dosyanın kaybolması gibi risklerle karşı karşıyadır. Sunucu tarafında tutulan ve düzenli yedeklenen bir sistemde bu risk büyük ölçüde ortadan kalkar; geçmiş dönemlere ait kayıtlara yıllar sonra bile erişilebilir olması, hem denetim hem de olası bir uyuşmazlık durumunda işletmeyi koruyan bir güvencedir.