Bulut Muhasebe API ile AB KDV Uyumluluğunu Otomatikleştirme

Gerçek defterlere, doğru KDV'ye ve yıllar sonra bile geçerliliğini koruyan bir denetim izine ihtiyaç duyan platformlar ve pazar yerleri için pratik bir rehber.

AB KDV'si artık bir hesaplama sorunu değildir. Bir kanıt sorunudur. Oranlar yayımlanmaktadır, eşikler bilinmektedir ve OSS beyannameleri belgelerle sabittir. Denetimlerde başarısız olunmasına ve platformların ölçeklenirken tıkanmasına yol açan şey, belirli bir faturadaki belirli bir KDV kararının o an var olan kurallar ve girdiler kullanılarak nasıl alındığının yeniden oluşturulamamasıdır. Bir bulut muhasebe API'si bunu baştan sona otomatik hale getirebilir; ancak yalnızca sadece orana göre değil, karar grafiği etrafında tasarlanmış olması koşuluyla.

Bu ayrım, aşağıdaki her şeyi şekillendirmektedir.

"AB KDV'sini otomatikleştirme" ifadesi aslında ne anlama gelir?

Birden fazla AB ülkesine satış yapan bir platform için KDV otomasyonu, birbirine bağlı kararlardan oluşan bir zincirdir:

Müşteri B2B mi yoksa B2C mi ve nerede bulunuyor?
Fatura tarihinde hangi ülkenin oranı, hangi vergi kategorisinde geçerlidir?
Tedarik tevkifata (reverse charge), OSS beyanına, IOSS beyanına mı tabidir yoksa yurtiçi mi?
Sorumlu tedarikçi (deemed supplier) pazar yeri miydi, yoksa tüccar mı?
Bu yanıtların her birini hangi kanıt desteklemektedir ve daha sonra tekrar gözden geçirilebilir mi?

Muhakeme sürecini otomatikleştirilmeksizin sadece rakamın otomatize edilmesi, klasik denetim başarısızlığının ortaya çıkmasına neden olur: doğru toplamlar, ancak savunulabilir bir iz yok. Modern vergi motorları, denetim düzeyinde kanıt izleri ve geçmiş oran sorgulamaları sunmaya odaklanmaktadır; çünkü denetimler artık sadece KDV'nin ne olduğuna değil, bu karara nasıl varıldığına odaklanmaktadır.

Bir bulut muhasebe API'si bu izi tutmak için en doğal yerdir; çünkü faturayı, yevmiye kaydını ve karşı tarafı zaten saklamaktadır. Nordlet tam olarak bu fikir etrafında inşa edilmiştir: değiştirilemez (immutable) çift taraflı defter, ülkeye özel KDV mantığı, VIES doğrulaması ve i.SAF beyanname üretimi; tüm bunlara tipli SDK'lar ve webhook'lar içeren tek bir REST yüzeyi üzerinden erişilebilmektedir. API, muhasebenin üzerine giydirilmiş basit bir katman değildir. Kararın kendisi için resmi kayıt sistemidir.

Ağırlığı sırtlayan üç API yeteneği

Çoğu KDV otomasyon çalışması, muhasebe API'sinin net bir şekilde sunması gereken üç yeteneğe indirgenir.

1. Tarihe endekslenmiş oran içeriği ve vergi kategorileri. Oranlar değişir. Kategoriler değişir. İndirimli oranlar eklenir ve kaldırılır. Sage'in AB KDV reformu ve muhasebe API'leri hakkındaki geliştirici kılavuzunda belirttiği gibi uygulanabilir model, kalemleri vergi kategorileriyle eşleştirmek, ardından vergi kategorilerini geçerlilik tarihleriyle birlikte ülkeye özel kodlarla eşleştirmektir. Her kalem için ülke başına bir oran kodlamak, bir yıl sonra bir oran değişikliği bir şeyi bozana kadar sessizce büyüyen hatalı bir yaklaşımdır.

2. Kademeli düşüş (graceful degradation) özelliğine sahip KDV Numarası doğrulaması. VIES, sınır ötesi B2B doğrulaması için temel kaynaktır. Aynı zamanda aralıklı olarak güven vermez. Mantıklı uygulamalar, doğrulamaları kısa Yaşam Süreleri (TTL) ile önbelleğe alır (cache), hata durumunda yeniden dener ve şüpheli durumlarda satışı engellemek yerine bir inceleme kuyruğuna yönlendirir. VIES'in her işlem için senkronize bir şekilde başarılı olması gerektiği fikri, platformların kendi kesintilerini bizzat yarattığı noktadır.

3. Kanıt toplama ve değiştirilemezlik (immutability). Her KDV kararı kendi girdilerini depolamalıdır: müşteri ülke sinyalleri, KDV numarası ve doğrulama zaman damgası, vergi kategorisi, oran tablosu sürümü, geçerli rejim (yurtiçi, OSS, IOSS, tevkifat) ve pazar yeri rolü. Bu kaydın oran değişikliklerine ve yapılandırma düzenlemelerine dayanması gerekir. Nordlet'in API düzeyinde uyguladığı dönem kilitleme özellikli değiştirilemez defter, daha sonraki bir denetimin daha derli toplu görünmesi için kapanmış bir ayın sessizce yeniden yaztıramayacağı anlamına gelir.

Bu üç yetenek temel seviyedir. OSS beyannamesi, i.SAF üretimi ve mutabakat dahil olmak üzere diğer her şey bunların üzerine oturur.

Sadece oranı değil, KDV kararını modellemek

Gömülü muhasebedeki en yaygın hata türü, faturadaki vergi alanını bir arama (lookup) işleminin çıktısı olarak ele almaktır. Öyle değildir. Küçük bir karar grafiğinin çıktısıdır ve saklanması gereken şey de bu grafiktir.

İşlenebilir bir model:

Karşı tarafı sınıflandırın. B2B veya B2C. B2B ise KDV numarasını VIES'e göre doğrulayın ve zaman damgası ile durum dahil olmak üzere yanıtı saklayın. B2C ise en az iki konum sinyali yakalayın: fatura adresi, IP veya coğrafi konum ve mümkünse ödeme aracının ülkesi.
Tedarik yerini belirleyin. Dijital hizmetler için KDV, tedarikçinin değil müşterinin konumunu takip eder. Mallar için kurallar sevkiyat menşei ve varış noktasına göre değişir. API, her fatura kalemini türetilmiş tedarik yeri ve kullanılan sinyallerle etiketlemelidir.
Rejimi seçin. Yurtiçi, OSS (AB içinde sınır ötesi B2C), IOSS (düşük değerli ithalat) veya tevkifat. Özellikle dijital hizmetler için 10.000 EUR tutarındaki sınır ötesi B2C eşiği gibi eşik mantığı, tek başına mevcut faturaya karşı değil, hareketli bir pencereye (rolling window) göre hesaplanmalıdır.
Oranı çözün. Fatura tarihindeki vergi kategorisi için ülkenin oranını sorgulayın. Kullanılan oran tablosu sürümünü saklayın.
Deftere kaydedin. OSS beyannamelerinin ve yurtiçi KDV beyannamelerinin veriler yeniden türetilmeden üretilebilmesi için ülkeye ve rejime göre bölünmüş ödenecek KDV ile çift taraflı yevmiye kaydı yazın.

Her adım API üzerinden izlenebilir olmalıdır. sale_invoice.paid gibi webhook'lar, alt sistemlerin yoklama (polling) yapmaksızın durum değişikliklerine tepki vermesini sağlar. İdempotensiy anahtarları (idempotency keys), yanlış anlık amanda bir ağ yeniden denemesi tetiklendiğinde yinelenen yevmiye kayıtlarını önler. Bunların ikisi de sıra dışı değildir, ancak platform ölçeğinde ikisi de vazgeçilmezdir.

OSS, IOSS ve 10.000 EUR eşiği

SaaS ve dijital hizmetler için pratik otomasyon sorunu OSS'dir. AB içinde sınır ötesi B2C satış yapan bir tedarikçi, cari veya önceki takvim yılında 10.000 EUR eşiği aşılana kadar kendi ülkesinin oranını uygular, bu eşik aşıldıktan sonra müşterinin üye devlet oranını uygular ve OSS aracılığıyla üç aylık raporlama yapar. SaaS ve dijital hizmetler için KDV uyumluluğu hakkındaki pratik rehberlik, bunu bir kayıt sorunu değil bir veri boru hattı (data pipeline) sorunu olarak ele almaktadır.

Muhasebe API'sinin desteklemesi gereken boru hattı:

Sınır ötesi B2C gelirini takvim yılı başına hareketli bir bazda eşiğe karşı takip edin.
Eşik aşıldığında, önceki faturaların tarihini geriye dönük olarak değiştirmeden oran çözümlemesini kendi ülkenizden varış ülkesine otomatik olarak geçirin.
Üç aylık OSS beyannamesi için işlemleri üye devlete, rejime ve para birimine göre gruplandırın.
OSS raporlaması için tutarları doğru döviz kuru tarihinde EUR cinsinden normalleştirin.
Beyannameyi verecek kişinin veya hizmetin tüketebileceği bir biçimde beyannameye hazır veri kümesini dışarı aktarın.

Nordlet bunu defterdeki ülkeye göre KDV mantığı ve rejim ile üye devlete göre gruplandıran raporlama yoluyla yönetir: OSS beyannameleri, önceki dönem düzeltmeleriyle birlikte doğrudan faturalardan hesaplanır ve 10.000 EUR eşiği otomatik olarak takip edilir. Beyanname, her çeyrekte sıfırdan yeniden oluşturulmaz, doğrudan defterden türetilir. Karar grafiğini ayrı bir e-tablo yerine muhasebe sisteminin içine koymanın amacı da budur.

IOSS, farklı bir eşik kümesi ve farklı bir beyanname ile düşük değerli ithalatlar için aynı kalıbı takip eder.

Pazar yeri ve platform akışları kendi kategorisindedir

Bir pazar yerini normal bir B2C kanalı olarak ele almak, şaşırtıcı sayıda uygulamanın hata yaptığı noktadır. Birçok AB senaryosunda platform sorumlu tedarikçidir (deemed supplier) ve KDV'yi tahsil etmekten ve ödemekten sorumludur. Tüccarın kendi muhasebesi, son müşteri değil platformun bu işlemler için KDV ile ilgili karşı taraf olduğunu yansıtmalıdır.

Gömülü bir muhasebe API'sinin hak ettiği değeri tam olarak kazandığı yer burasıdır. Platform, satış anında sorumlu tedarikçi olarak hareket edip etmediğini bilir. Bu gerçeğin fatura kaydına yazılması ve deftere aktarılması gerekir; böylece tüccarın defterleri, platformun halihazırda ele aldığı KDV'yi mükerrer saymaz. Vergi rolü göstergelerini API üzerinden geçirmek ve bunları raporlarda yansıtmak, temiz defterler ile hiçbir zaman tam olarak tutmayan bir mutabakat arasındaki farktır.

Nordlet üzerinde geliştirme yapan platformlar için bu birinci sınıf bir özelliktir: faturalar bir vatScheme (marketplace_deemed dahil) ve bir deemedSupplier bayrağı taşır ve muamele çözümleyici (treatment resolver), 2006/112/EC Yönergesi kapsamındaki yasal dayanağıyla birlikte geçerli rejimi döndürür. Çoklu şirket desteğiyle birleştirildiğinde, platformun muhasebesi ve tüccarın muhasebesi, KDV kayıtlarını aralarında sızdırmadan, farklı şirketler ve farklı rollerle aynı API altında yaşayabilir.

ViDA'nın değiştirdiği ve değiştiremediği şeyler

Dijital Çağda KDV (ViDA), otomasyonun biçimini "hesapla ve kaydet" aşamasından "hesapla, kaydet ve ilet" aşamasına taşır. E-fatura ve vergi otoritelerine yakın gerçek zamanlı raporlama, boru hattının bir parçası haline gelir. Bu durum muhasebe API'sinin yerini almaz. Muhasebe API'sinin yapılandırılmış fatura verilerini, raporlama ağ geçidine yansıtılacak kaynak haline getirir.

İki pratik sonucu vardır:

Fatura meta verilerinin eski şemaların çoğunun izin verdiğinden daha zengin olması gerekir. Peppol BIS 3.0 alanları, satır başına yapılandırılmış KDV dökümü ve rejim tanımlayıcıları, serbest metin notları olarak iliştirilmiş değil, muhasebe API'sinde birinci sınıf unsurlar olmalıdır.
Muhasebe belgesi ile raporlanan belge senkronize kalmalıdır. Bir alacak dekontu düzenlenirse, raporlama ağ geçidinin düzeltmeyi aynı tanımlayıcılarla görmesi gerekir. Değiştirilemez defterler ve net belge soy kütüğü bunu basitleştirir. Gevşek muhasebe ise bunu zahmetli hale getirir.

ViDA'ya hazırlanmak, yeni özelliklerden çok halihazırda var olan şeylerin disiplinini sıkılaştırmakla ilgilidir.

Otomasyon yaklaşımlarının kısa bir karşılaştırması

Yaklaşım	KDV karar kanıtı	OSS/IOSS yönetimi	Pazar yeri rol Modellemesi	Gömülü platformlar için uygunluk
E-tablolarla manuel muhasebe	Zayıf, olay sonrasında yeniden oluşturulur	Manuel, hataya açık	Genellikle göz ardı edilir	Düşük
Vergi modülü eklenmiş eski muhasebe yazılımı	Kısmi, genellikle defterin dışında	Destekleniyor ancak izole	Sınırlı	Düşük ila orta
Genel muhasebe API'si (Xero, QuickBooks tarzı)	Entegrasyon disiplinine bağlı	Pazara ve eklentiye göre değişir	AB bağlamında sorumlu tedarikçi akışları için genel olarak doğrulanmamış	Orta
Nordlet (API odaklı, AB odaklı)	Değiştirilemez defter, fatura başına vergi meta verileri, dönem kilitleme	Yerel ülkeye göre KDV, i.SAF, VIES, OSS'ye hazır gruplama	Birinci sınıf: Fatura başına `vatScheme`, `deemedSupplier`	Yüksek

Tablo, bu makale için mevcut olan girdileri yansıtır. Rakip bir yeteneğin araştırma özetinde belgelenmediği durumlarda, varsayımda bulunmak yerine halka açık olarak doğrulanmamış bırakılmıştır.

Şimdi başlıyorsanız ilk olarak neyi inşa etmelisiniz?

Bir ekip, bulut muhasebe API'si üzerinde gömülü AB KDV otomasyonu kuruyorsa, en çok yeniden çalışma (rework) maliyetinden kurtaracak sıra şöyledir:

Her şeyden önce karşı tarafı ve onun ülke sinyallerini modelleyin. Sonraki tüm kararlar buna bağlıdır. Türetilmiş ülkeyi değil, sinyalleri saklayın.
Vergi kategorisi katmanını oluşturun. Ürünleri ve hizmetleri kategorilere eşleyin. Kategorileri ülke kodlarına eşleyin. Ürünleri asla doğrudan oranlarla eşleştirmeyin.
VIES doğrulamasını önbellekleme ve inceleme kuyruğuyla bağlayın. VIES kullanılabilirliğinin ödeme işleminizi (checkout) engellemesine izin vermeyin.
Fatura durumu değişiklikleri için webhook'lar yayınlayın ve tüketin. Her yazma işleminde idempotensiy anahtarları kullanın.
Dönemleri kapanır kapanmaz kilitleyin. Politikada değil, API'de uygulayın.
OSS beyannamelerini defterden türetin. Beyanname ayrı bir e-tablo gerektiriyorsa, defter yeterli meta veri taşımıyor demektir.
Yalnızca bunlardan sonra e-fatura ve raporlama ağ geçidi entegrasyonunu ekleyin. Yukarı akış verilerinin önce doğru olması gerekir.

Bunların çoğu, her çeyrekte sessizce karşılığını veren bir defaya mahsus yatırımlardır. Sınırsız bir sandbox şirketi, sırayı baştan sona kanıtlamak için en ucuz yerdir.

FAQ

VIES doğrulaması, B2B satışın doğru şekilde sıfır oranlı (zero-rated) olduğunu kanıtlamak için yeterli midir?

Tek başına değildir. VIES, bir KDV numarasının belirli bir zamanda geçerli olduğunu onaylar. Denetime dayanıklı kayıt ayrıca kontrolün zaman damgasını, yanıt yükünü, müşterinin beyan ettiği ülkeyi ve mal veya hizmetlerin KDV kayıtlı bu tüzel kişiliğe tedarik edildiğine dair kanıtı içerir. Hepsini faturaya karşı saklayın.

Bir platform, KDV'yi yönetmesi için pazar yerine güvenebilir ve kendi mantığını atlayabilir mi?

Yalnızca pazar yerinin AB kuralları altında sorumlu tedarikçi olduğu belirli işlemler için. Tüccarın muhasebesinin yine de bu işlemleri doğru bir şekilde yansıtması gerekir ve doğrudan satışlar ile B2B akışları dahil olmak üzere bu kapsamın dışındaki tüm satışlar tüccarın sorumluluğunda kalmaya devam eder. Daha güvenli varsayılan yaklaşım, rolü işlem bazında açıkça modellemektir.

AB KDV oranları gerçekte ne sıklıkla önemlidir derecede değişir?

Kodlanmış oranların gerçek sorunlara yol açacağı kadar sık değişir. İndirimli oran kategorileri kayar, geçici oranlar sunulur ve süresi dolar, yeni üye devlet kuralları ortaya çıkar. Geçerlilik tarihlerine sahip bir oran içerik katmanı aşırı mühendislik değildir. Temel gereksinimdir.

Pratikte OSS ve IOSS arasındaki fark nedir?

OSS, AB içinde sınır ötesi B2C mal ve dijital hizmet satışlarını kapsar ve tek bir üye devlet aracılığıyla üç ayda bir bildirilir. IOSS, AB'ye yapılan düşük değerli ithalatları, tipik olarak 150 EUR altındaki tüketici mallarını kapsar. Her ikisi de defter her işlemini rejimiyle etiketlerse aynı muhasebe verilerinden türetilir.

Değiştirilemez (immutable) bir defter, düzeltmelerin imkansız olduğu anlamına mı gelir?

Hayır. Düzeltmeler eskileri düzenleyerek değil, yeni girdiler yoluyla yapılır. Bir alacak dekontu faturayı tersine çevirir, ters kayıt hatalı bir postalamayı düzeltir. Değiştirilemezliğin önlediği şey, denetçilerin tam olarak aradığı davranış olan tarihin sessizce yeniden yazılmasıdır.