Çoğu işletme sahibi göçü teknik bir olay sanır: sunucu, veritabanı, tema, teslimat. Muhasebe ise "sonra hallolur" rafına konur. Gerçekte muhasebe, göçün en erken patlayan ve en geç fark edilen parçasıdır. Teknik hatayı aynı gece görürsün; muhasebe hatasını üç ay sonra, bir mutabakat farkı ya da bir denetim sorusu yüzünden görürsün. O noktada geriye dönüp düzeltmek, göçün kendisinden pahalıdır.
Sebebi basit: teknik sistem "şu an" ile ilgilenir, muhasebe "geçmişin tamamı" ile. Yeni dijital ürün satış scripti bugünün siparişini mükemmel işlese bile, dünün faturasını bulamıyorsan, numara sırası kırıldıysa veya bakiye toplamı tutmuyorsa sistem senin için çalışmıyor demektir. Bu yazıda göç ederken muhasebe sürekliliğini nasıl koruyacağını, hangi anı nasıl mühürleyeceğini ve mutabakat farklarının nereden çıktığını anlatıyorum.
Muhasebe Neden Göçün En Son Düşünülen, En Erken Patlayan Parçası?
Göç ekibi genelde "çalışıyor mu" sorusuna odaklanır. Sipariş geçiyor, kod teslim ediliyor, ödeme düşüyor; herkes rahatlar. Ama muhasebenin sorusu farklıdır: "toplamlar eşit mi ve her satır izlenebilir mi?" Bu iki soruya "evet" demek için sadece verinin taşınması yetmez; verinin anlamının da taşınması gerekir.
Örnek: eski sistemde sipariş tutarı komisyon düşülmüş net tutarken, yeni sistemde brüt tutar olarak yorumlanıyorsa her satır doğru görünür ama yıllık ciro yanlış çıkar. Ya da eski sistemde iadeler ayrı bir tabloda tutulurken yeni sistemde siparişin durumu olarak işleniyorsa, iade edilmiş satışlar ciroya dahil olmaya devam eder. Hiçbir hata mesajı görmezsin. Sadece rakamlar yanlıştır ve bunu ancak vergi dönemi söyler.
Fatura Numarası Sırası: Tek Kırılma, Tüm Yılı Sorgulatır
Fatura ve sipariş numaraları muhasebenin omurgasıdır. Numara serisinde boşluk varsa "acaba bir satış gizlendi mi", tekrar varsa "acaba çift kayıt mı" sorusu doğar. Göç sırasında bu iki hata çok kolay oluşur çünkü yeni sistem kendi sayacını sıfırdan başlatır. Sonuç: 2026'nın ilk yarısında 14.500'e kadar giden seri, göç gecesi 1'e döner ve sen aynı yıl içinde iki kez "fatura no 120" üretirsin.
Doğru yöntem üç adımdır. Bir: kesinti anında eski sistemin son kullandığı numarayı yaz. İki: yeni sistemin sayacını o numaranın bir üstünden başlat. Üç: eski kayıtlar taşınırken numaralarını asla yeniden üretme, olduğu gibi koru. Ayrıca eski ve yeni dönemi ayırt etmek için ön ek kullanmak istiyorsan, bunu yıl başında yap; yıl ortasında ön ek değiştirmek denetimde ekstra açıklama gerektirir. İyi bir e-pin satış yazılımı bu sayacı yapılandırılabilir bırakır; bırakmıyorsa göç öncesi sorulacak ilk soru budur.
| Kalem | Kesinti anında yapılacak | Yeni sistemde karşılığı | Risk |
|---|---|---|---|
| Fatura numarası | Son numara yazılır | Sayaç son+1'den başlatılır | Yüksek: seri kırılması denetim sorusu doğurur |
| Sipariş numarası | Son numara yazılır | Devam ettirilir, taşınanlar korunur | Yüksek: çift numara destek karmaşası |
| Cüzdan bakiyeleri | Toplam ve hesap bazında dökülür | Toplam birebir eşleşmeli | Çok yüksek: bakiye bir borç kalemidir |
| Bekleyen siparişler | Liste dondurulur | Elle tamamlanır, otomatiğe bırakılmaz | Orta: çift teslimat riski |
| Açık iade talepleri | Tutarları not edilir | Yeni sistemde iade kaydı olarak açılır | Orta: ciro şişmesi |
| Ödeme sağlayıcı hareketleri | Gün kapanışı indirilir | Mutabakat referansı olur | Yüksek: komisyon farkı gizlenir |
| Kur kuru (dövizli ürünler) | Kesinti anındaki kur yazılır | Aynı kurla açılış yapılır | Orta: kur farkı raporu bozar |
İki Sistemde Aynı Gün: Kesinti Anı Nasıl Mühürlenir?
Muhasebe sürekliliğinin tek sihirli kavramı budur: mühür. Göç gecesi belirlediğin saniyede eski sistem kapanır ve o andaki durumu bir kapanış kaydı hâline getirirsin. Kapanış kaydı en az şunları içerir: toplam cüzdan bakiyesi, açık sipariş sayısı ve tutarı, son fatura ve sipariş numarası, kasa/sağlayıcı bazında o güne kadarki tahsilat toplamı, açık iade tutarı ve kullanılan kur.
Bu kayıt tek sayfa olur, tarih ve saat damgası taşır ve iki yere kopyalanır. Neden bu kadar önemli? Çünkü göçten sonra çıkan her soru bu sayfayla cevaplanır. "Bu 3.400 lira nereden geldi?" sorusunun cevabı ya mühürden öncedir ya sonrasıdır; arada kalan hiçbir şey yoktur. Mühür yoksa her fark tartışmaya açıktır ve tartışmalar günler alır.
Göç sonrası mutabakat farklarının kaynak dağılımı
- Komisyon ve brüt/net karışması 45%
- İade ve iptal kayıtları 25%
- Cüzdan ve bonus bakiyeleri 20%
- Kur farkı ve yuvarlama 10%
Cüzdan Bakiyesi Bir Borç Kalemidir, Ürün Değil
Dijital ürün satışında cüzdan çok yaygındır ve muhasebede en çok yanlış anlaşılan kalemdir. Müşterinin cüzdanında duran para senin cironun parçası değildir; senin ona olan borcundur. Gelir, o bakiye harcandığında doğar. Bu ayrımı yapmayan işletmeler yükleme anında ciro yazar, harcama anında bir kez daha yazar ve yıl sonunda olmayan bir büyümeyi kutlar.
Göç bu hatayı büyüteç altına alır. Eğer eski sistemde bakiye tek alan, yeni sistemde "yüklenen bakiye" ve "kampanya bakiyesi" olarak ikiye ayrılıyorsa, toplamı eşitlemek yetmez; hangi kısmın gerçek borç, hangisinin promosyon karşılığı olduğunu da ayırmak gerekir. Doğru kurulmuş bir e-pin scripti bu iki havuzu ayrı tutar ve her hareket için kaynak bilgisi yazar. Göç günü hesap bazında bakiye dökümü almak, sonradan çıkacak yüzlerce soruyu peşinen kapatır.
Göç yapılan ayı takvimde ayrı bir dönem gibi ele al: eski sistemden mühre kadar, yeni sistemden mühürden sonra rapor al, ikisini topla ve sağlayıcı ekstresiyle karşılaştır. Ayı tek parça rapor almaya çalışmak, farkı bulmanı imkânsızlaştırır.
Komisyon, İade ve Kur Farkı: Raporlar Neden Uyuşmuyor?
Mutabakat farklarının büyük kısmı üç klasikten çıkar. Birincisi komisyon: ödeme sağlayıcı sana net tutar yatırır, sistemin ise brüt tutarı satış olarak kaydeder. Aradaki fark gider kalemidir; giderleştirilmezse hem ciro hem kâr yanlış görünür. İkincisi iade: yeni sistemde iade, siparişin durumunu değiştirerek işleniyorsa geçmiş rapor da geriye dönük değişir ve dün aldığın raporla bugün aldığın rapor uyuşmaz. Doğru yaklaşım iadeyi ayrı bir kayıt olarak yazmaktır.
Üçüncüsü kur ve yuvarlama: dövizle alıp lirayla sattığın ürünlerde kur hangi anda sabitleniyor sorusu kritiktir. Sipariş anı mı, teslim anı mı, gün sonu mu? Göç sırasında bu kural değişirse aynı ürünün maliyeti farklı hesaplanır ve kâr marjı sahte biçimde oynar. Bu üç kuralı yazılı hâle getirip yeni epin yazılım ayarlarına birebir yansıtmak, göç sonrası raporlara güvenmenin ön şartıdır.
Denetime Hazır Arşiv: On Yıl Sonra Bu Kayıtları Kim Açacak?
Son mesele arşiv. Eski sistemi kapatıyorsun, ama geçmiş kayıtları sorulduğunda üretebilmen gerekiyor. Buradaki tuzak, arşivi eski yazılıma bağımlı bırakmaktır: veritabanı yedeği duruyor ama o yedeği okuyabilen panel artık kurulamıyorsa elinde kullanılabilir bir arşiv yok demektir.
Çözüm, arşivi yazılımdan bağımsız biçimde çıkarmaktır. Fatura ve sipariş listelerini insan okuyabilir tablo dosyaları olarak, fatura belgelerini sabit biçimli dosyalar olarak sakla; hepsini yıl ve ay klasörlerine ayır, bir de içindekiler dosyası ekle. Buna ek olarak ham veritabanı yedeğini de tut ama ona tek dayanağın olarak güvenme. Böylece beş yıl sonra gelen bir soruya, hangi yazılımı kullandığından bağımsız olarak on dakikada cevap verebilirsin.
| Kontrol | Ne zaman | Kanıt | Tamam mı? |
|---|---|---|---|
| Kapanış kaydı (mühür) tek sayfa hazırlandı | Kesinti anı | Tarih-saat damgalı dosya | □ |
| Fatura sayacı son numaranın üstünden başlatıldı | Satış açılmadan önce | Test faturası numarası | □ |
| Toplam cüzdan bakiyesi iki sistemde eşit | Kesinti anı | İki sistemden alınan toplam | □ |
| Yüklenen ve kampanya bakiyesi ayrıştırıldı | Göç öncesi | Hesap bazında döküm | □ |
| Komisyonun gider olarak işlendiği doğrulandı | İlk hafta | Sağlayıcı ekstresi karşılaştırması | □ |
| İadeler ayrı kayıt olarak açılıyor | İlk hafta | Örnek iade kaydı | □ |
| Kur sabitleme anı kuralı yazıldı ve ayarlandı | Göç öncesi | Ayar ekranı ve yazılı kural | □ |
| Yazılımdan bağımsız arşiv çıkarıldı | Gölge dönem sonu | Yıl/ay klasörleri + içindekiler | □ |
| Göç ayı iki parçalı olarak mutabık kılındı | Ay sonu | Toplam = eski + yeni | □ |
Rakamlarına güvenebildiğin bir altyapı kur
Pinova, e-pin ve dijital ürün satan işletmeler için hazırlanmış lisanslı satış yönetim yazılımıdır. Ayrı bakiye havuzları, iade kayıtları ve yapılandırılabilir numara serileriyle muhasebe sürekliliğini korumak üzere tasarlanmıştır.
Fatura numaralarını yeni sistemde sıfırdan başlatabilir miyim?
Yıl ortasında başlatmamalısın; aynı yıl içinde tekrarlayan numaralar oluşur. Doğru yol, kesinti anındaki son numarayı yazıp yeni sayacı onun bir üstünden başlatmaktır. Sıfırdan başlatmak istiyorsan bunu yıl başına denk getir.
Cüzdan bakiyesini ciro olarak yazmak doğru mu?
Hayır. Yükleme anında para senin borcundur, gelir değildir; gelir bakiye harcanıp ürün teslim edildiğinde doğar. Aksi hâlde hem ciroyu şişirir hem aynı tutarı iki kez sayarsın.
Göç ayının raporunu tek parça alabilir miyim?
Alamazsın ve almaya çalışmamalısın. O ayı iki parça gör: eski sistemden mühre kadar, yeni sistemden mühürden sonra. İki raporun toplamı sağlayıcı ekstresiyle karşılaştırılır; fark çıkarsa hangi tarafta olduğu hemen belli olur.
Eski sistemi kapattıktan sonra geçmiş faturalara nasıl ulaşırım?
Arşivi yazılımdan bağımsız çıkararak. Fatura ve sipariş listelerini tablo dosyası, belgeleri sabit biçimli dosya olarak yıl/ay klasörlerinde sakla. Ham veritabanı yedeği de dursun ama tek dayanağın o olmasın.
Muhasebe tarafını konuşurken en hızlı ilerleme yolu, raporların ve bakiye hareketlerinin nasıl tutulduğunu kendi gözünle görmekten geçiyor: özellik listesine bak, canlı demo içinde cüzdan hareketi, iade kaydı ve sipariş raporunu test et, fiyat tarafı netleştiğinde panelden kuruluma geç.