Gömülü Muhasebe: Pazaryerleri İçin Kendin Yap veya Satın Al

Kapsam listesi, varsayımlarıyla birlikte bir maliyet modeli ve her bir yanıtın doğru olduğu koşullar.

Her pazaryeri eninde sonunda bir defter-i kebir (ledger) inşa eder. Tek soru, bunun denetim mekanizmalarına sahip bilinçli bir sistem olarak mı, yoksa üç farklı servisin veri yazdığı ve kimsenin tam olarak güvenmediği bir balance (bakiye) sütunu olarak kazara mı ortaya çıkacağıdır.

Bu makale, bu seçimi bilinçli bir şekilde yapmanızı ele almaktadır. Sürecin gerçekten neleri kapsadığını, kendinizi kandırmadan maliyeti nasıl hesaplayacağınızı ve geliştirmenin neden doğru karar olabileceğini (çünkü bazen gerçekten öyledir) özel koşullarıyla birlikte inceliyor.

Buradaki "gömülü muhasebe" (embedded accounting) ne anlama geliyor?

Gömülü muhasebe, finansal kayıtların birinin ayrıca açtığı bir uygulamada değil, doğrudan ürününüzün içinde yer alması anlamına gelir. Yazılımınız olaylar gerçekleştikçe yevmiye kayıtlarını (entries) oluşturur, kullanıcılarınız arayüzünüzün onlara gösterdiği her şeyi görür ve ay sonunda kimse muhasebeciye göndermek için Excel tablosu dışarı aktarmaz.

Bir pazaryeri için bu durum en azından şunları kapsar: alınan alıcı ödemeleri, satıcılara olan borçlar, kazanılan komisyonlar, ödeme işleme ücretleri, ücretleriniz ve temel arz üzerindeki KDV, iadeler, ters ibrazlar (chargebacks), ihtiyat akçeleri (reserves), ödemeler (payouts) ve tüm bunların bir banka veya ödeme sağlayıcısı ile mutabakatı.

Geliştirmeyi seçtiğinizde aslında ne inşa ediyorsunuz?

Defter-i kebirin kendisi işin küçük bir kısmıdır. Ekipler genellikle ilk kalemi planlar ve geriye kalanları sonradan keşfederler.

Bileşen	Neleri kapsar?
Yevmiye ve hesaplar	Dengeli kayıtlar, hesap planı, hesap türleri, açılış bakiyeleri
Değiştirilemezlik (immutability)	Sadece ekleme yapılabilen depolama (append-only storage), ters kayıt (reversal) ve düzeltme iş akışı, yerinde düzenleme (in-place edit) olmaması
Dönem kontrolü	Kapatma, kilitleme, gecikmiş yevmiye kayıtlarını reddetme, denetim iziyle (audit record) kontrollü yeniden açma
Tekrar edilebilirlik (idempotency)	Anahtarlar, önceki yanıtların saklanması, değiştirilen veri yüklerinde (payloads) çakışma tespiti
Para birimi yönetimi	Tam ondalık veya kuruş bazlı aritmetik, para birimi kodları, döviz kurları ve kaynakları, yuvarlama hesapları
KDV motoru	Geçerlilik tarihleriyle birlikte ülkeye özel oranlar, teslim yeri, tevkifat (reverse charge), sorumlu sıfatı (deemed supplier) kuralları, istisnalar
KDV kimlik kontrolleri	Resmi kayıtla doğrulama, önbellekleme, zaman damgaları, istek tanımlayıcıları, hatalar için manuel inceleme kuyruğu
Belgeler	Faturalar, alacak dekontları (credit notes), seri ve yıla göre boşluksuz numaralandırma, PDF oluşturma, teslimat
Elektronik faturalandırma	EN 16931 UBL gibi yapılandırılmış formatlar ve zorunlu olduğu durumlarda ülkeye özel ulusal formatlar
Banka veri aktarımı	Ekstre içe aktarma veya onaylı bir banka bağlantısı, halihazırda içe aktarılmış işlemlerin mükerrer olmasını önleme
Mutabakat (reconciliation)	Eşleştirme kuralları, puanlama, kısmi eşleşmeler, bir insanın çözebileceği istisnalar
Ödemeler (payouts)	Ödeme dosyası oluşturma, ödeme gruplama, ödemeleri temel öğelerle yeniden eşleştirme
Raporlama	Mizan (trial balance), bilanço, gelir tablosu, nakit akışı, KDV özetleri, yaşlandırma raporları
Vergi defterleri ve beyannameler	Ülkelerinizin gerektirdiği her şey, vergi dairelerinin kabul ettiği formatta
Denetim (audit)	Her değişiklik için sorgulanabilir nitelikte aktör, eylem, varlık ve değişikliğin kendisi
Saklama ve dışa aktarma	OSS kayıtları için on yıllık saklama süresi, tam veri dışa aktarımı, savunulabilir arşiv

Çoğu ekibin "bir defter-i kebir inşa edeceğiz" derken gözünde canlandırdığı kısım, bu on yedi satırdan kabaca ikisidir.

Maliyeti dürüstçe hesaplamak

Buradaki her rakam sizin ekibinize bağlıdır; bu nedenle aşağıdaki adımları kesin bir fiyat teklifiten ziyade bir yöntem olarak ele alın. Yukarıdaki bileşenleri ele alın, kendi ekibinizin hızına (velocity) göre her birine mühendis-hafta cinsinden bir boyut atayın ve ardından tahminlerin genellikle göz ardı ettiği üç düzeltmeyi uygulayın.

Birinci düzeltme: uyumluluk bileşenleri tek seferlik değildir. Oranlar değişir, eşikler değişir, formatlar değişir ve AB'nin Dijital Çağda KDV (VAT in the Digital Age) paketi tarihe bağlı yükümlülükler getirir; 1 Ocak 2027 itibarıyla OSS ve IOSS değişiklikleri, 1 Temmuz 2028 itibarıyla genişletilmiş platform kuralları, 1 Temmuz 2030 itibarıyla sınır ötesi dijital raporlama bunlardan bazılarıdır. İnşa etmek demek, bu geçişlerin her birinin sorumluluğunu üstlenmek demektir.

İkinci düzeltme: doğruluk çalışmaları özellik geliştirmeden daha uzun sürer. İlk sürüm ideal senaryoları (happy path) yönetir. Uzun kuyruk ise ödeme yapıldıktan sonraki iadeler, kısmi iadeler, haftalar sonra gelen ters ibrazlar, para birimi yuvarlamaları, mükerrer webhooks ve kayıtlarınızla uyuşmayan mutabakat dosyalarıdır. Takvimin su gibi akıp gittiği yer burasıdır.

Üçüncü düzeltme: muhasebeci bir gözden geçiren değil, bir paydaştır. Bir finans profesyonelinin onaylamayacağı defterler bitmiş sayılmaz ve bu geri bildirim bir inşa sürecinde çok geç gelir.

Faydalı bir mantık kontrolü: en küçük güvenilir inşanın fiyatını çıkarın; defter-i kebir, düzeltmeler, dönem kilitleme, tekrar edilebilirlik (idempotency), para birimi yönetimi, tek bir ülkenin KDV'si, faturalar, banka veri aktarımı, eşleştirme ve temel bir rapor seti dahil edin ve bunu faturalı bir servisin yıllık maliyetiyle karşılaştırın. Nordlet'in yayınlanan planları 3.000 istek dahil olmak üzere ayda 10 €'dan başlar ve 200.000 istek içeren paketlerde ayda 300 €'ya kadar çıkar. Eğer bir inşa süreci tek bir mühendis-yılın maliyetinin çok küçük bir kısmına mal oluyorsa, bu inşa etmek için geçerli bir argümandır. Ancak birkaç mühendis-yıl artı sürekli bakım maliyeti gerektiriyorsa, karşılaştırma yapılamaz bile ve kurallar değiştikçe bu fark daha da açılır.

Geliştirmek ne zaman gerçekten doğrudur?

Üç senaryo vardır ve üçü de gerçektir.

Defter-i kebiriniz sizin ürününüzdür. Eğer bir ödeme platformu, bankacılık ürünü veya eşzamanlılık (concurrency) altında bakiye davranışının ayırt edici özellik olduğu bir cüzdan inşa ediyorsanız, defter-i kebir çekirdek bileşendir ve size ait olmalıdır. Sıfırdan inşa etmek yerine defter-i kebir altyapı ürünlerini değerlendirin ve yasal muhasebeyi ayrı tutun.

Modeliniz hiçbir muhasebe sistemine uymuyor. Bazı pazaryerleri gerçekten olağandışı mutabakat yapılarına sahiptir; koordine serbest bırakma mekanizmalarına sahip çok taraflı paylaşımlar, kademeli aşamalara sahip emanet (escrow) hesapları, karmaşık ihtiyat akçesi politikaları gibi. Hiçbir ürün bunu modellemiyorsa ve geçici çözümler inşadan daha kötüyse, inşa edin.

Hacminiz ölçümlü fiyatlandırmayı (metered pricing) yanlış kılıyor. Yeterince uç işlem oranlarında, istek başına fiyatlandırma cazibesini yitirir. Bunu varsaymadan önce gerçek rakamlarla modelleyin, çünkü buradaki "uç" tanımı çoğu platformun ulaştığından daha yüksektir.

Satın almak ne zaman doğrudur?

Muhasebe gerekli olduğunda ancak ayırt edici (differentiating) bir özellik olmadığında satın almak kazançlıdır ki bu yaygın olan durumdur. Hiç kimse yevmiye kayıtlarınız zarif olduğu için pazaryerinizi seçmez. Sadece hesaplar yanlış olduğunda bunu fark ederler.

Satın almak, yükümlülükleriniz çok ülkeli olduğunda da doğru karardır. Ülkeye özel KDV kuralları, kanıt saklama ve e-fatura zorunlulukları kalıcı bir bakım yüküdür ve bir satıcı bu işin maliyetini her müşteriye paylaştırır (amortize eder). Nordlet, planlayacağınız bir proje olarak değil, ürünün bir parçası olarak VIES doğrulaması, OSS ve IOSS beyanname hesaplaması, i.SAF defterleri ve Peppol için EN 16931 UBL içeren ülkeye özel AB KDV'sini sunar.

Çoğu ekibin ulaştığı orta yol

Pratik yanıt genellikle bu ikisinden biri değildir. Şudur: Defter-i kebiri satın alın, iş akışını inşa edin.

Muhasebe arka ucu yevmiye kayıtlarının, vergi işlemlerinin, belgelerin, dönem kapama işlemlerinin ve denetim izinin sahibidir. Ürününüz ise kullanıcılarınızın gördüğü her şeyin ve pazaryerinize özgü her iş kuralının sahibidir; fonların ne zaman serbest bırakılacağı, ihtiyat akçesi politikasının ne olduğu, uyuşmazlıkların nasıl ele alındığı, satıcı panelinde ne gösterildiği gibi. Para taahhüt edildiği anda muhasebe API'sini çağırırsınız ve gerçekten size ait olan kısımları kendiniz tutarsınız.

Bu sınır, alternatiflerine göre değişikliklere karşı da daha iyi dayanır. Yeni bir ülke, bir proje yerine sadece bir yapılandırma ekler. Yeni bir ödeme politikası bir satıcı talebi değil, sizin kodunuz olur.

Taahhütte bulunmadan önce karar vermeniz gerekenler

Defter-i kebiriniz ayırt edici bir özellik mi yoksa bir zorunluluk mu? Dürüst olun; birçoğu sadece bir zorunluluktur.
Kaç ülke var ve her biri ne gerektiriyor? Sadece oranlar mı, yoksa beyannameler mi, defterler mi veya beyanname gönderimi mi?
Düzeltme (correction) senaryonuz nedir? Ödeme sonrasındaki iadeler ve gecikmiş ters ibrazlar, zayıf bir tasarımı açığa çıkaran durumlardır.
Defterleri kim onaylıyor? Tasarım netleştikten sonra değil, tasarım aşamasındayken o kişiyi dahil edin.
On yıllık saklama planı nedir? OSS kayıtları, işlemin yapıldığı yılın sonundan itibaren on yıl süreyle saklanmalıdır ve arşiv bir yedekleme değil, bir sistemdir.
Üç yıl sonra bir geçiş (migration) nasıl görünecek? Her iki yön için de. İlk gün bir test dışa aktarımı oluşturun ve çalışır durumda tutun.

FAQ

Bir pazaryeri defter-i kebiri ne kadar sürede inşa edilir?

Dengeli kayıtlar oluşturan ilk sürüm haftalar içinde çalışır hale gelebilir. Ödeme sonrası iadeleri, gecikmiş ters ibrazları, çoklu para birimi yuvarlamalarını, mükerrer sağlayıcı webhooks işlemlerini, dönem kapama süreçlerini ve bir muhasebecinin kabul edeceği bir denetimi yöneten bir sürüm ise çok daha uzun sürer ve bakım hiç bitmez. İkinci seçeneği tahmin edin, çünkü üretim ortamı (production) tam olarak bunu gerektirir.

Bir `balance` sütunuyla başlayıp daha sonra geçiş yapabilir miyiz?

Yapabilirsiniz ve pek çok kişi de bunu yapar, ancak geçişin orijinal inşadan daha zor olacağını hesaba katın. Değiştirilebilir (mutable) bir bakiyeden geçmişi yeniden oluşturmak, yalnızca onu değiştiren her olayı sakladıysanız mümkündür; bu da ancak halihazırda bir defter-i kebiriniz varsa mümkündür.

Gömülü bir muhasebe API'si finans ekibimizin yerini alır mı?

Hayır. Manuel kaydı ve mutabakatı ortadan kaldırır. Yine de birileri ay sonunu kapatır, istisnaları inceler, kararlar alır ve beyannameleri verir.

Defter-i kebir değiştirilemez (immutable) ise GDPR durumu ne olacak?

Finansal gerçekleri ve takma ad (pseudonymous) içeren referansları değiştirilemez kayıtlarda tutun; kişisel bilgileri ise kendi saklama ve silme süreçlerine sahip ayrı bir sistemde saklayın. Değiştirilemezlik kuralı, ona bağlı her öznitelik için değil, finansal olay için geçerlidir.

Açık kaynaklı muhasebe yazılımı orta bir seçenek midir?

Gerçek bir seçenektir ve maliyeti ortadan kaldırmak yerine sadece şeklini değiştirir: barındırma (hosting), güncellemeler, ülkeye özel yerelleştirme (localisation) ve uyumluluk güncellemelerini kendiniz üstlenirsiniz. Lisans tasarrufunu resmin tamamı olarak görmeden önce bunları fiyatlandırın.