VERI*FACTU ve Size Özel Faturalama Yazılımı: 2027 Son Tarihi ve Duyurulan 2028 Ertelemesi

İspanya'da kurumlar vergisi (Impuesto sobre Sociedades) beyannamesi veren ve faturasını yazılımla düzenleyen her şirket, 1 Ocak 2027'den önce Real Decreto 1007/2023'e uyarlanmış bir yazılım kullanıyor olmak zorunda. Her fatura için bir öncekine zincirlenmiş, hash'i alınmış bir kayıt oluşturulur ve faturaya, müşterinin vergi idaresi üzerinden doğrulayabileceği bir QR kod eklenir. Kapsamdaki diğer herkesin, yani çoğunlukla serbest çalışanların, 1 Temmuz 2027'ye kadar süresi var. 5 Ekim 2026'da Maliye Bakanlığı bu yükümlülükleri Ekim 2028'e erteleyeceğini duyurdu. 16 Ekim itibarıyla bunu yapan hiçbir düzenleme yayımlanmadı; dolayısıyla 2027 tarihleri hâlâ bağlayıcı.

Faturalarınız ticari bir paketten çıkıyorsa bu iş büyük ölçüde yazılım sağlayıcınızın. Sizin için birinin yazdığı ya da kendi ekibinizin geliştirdiği bir yazılımdan çıkıyorsa iş sizin. Kodu siz değiştirirsiniz ve uyumlu olduğunu söyleyen beyanı da siz imzalarsınız.

Tarihler ve İki Erteleme

Bu, üçüncü tarih takvimi; biraz şüpheci olmak yerinde.

• Real Decreto 1007/2023 başlangıçta işletmelere 1 Temmuz 2025'e kadar süre tanıyordu.
• Real Decreto 254/2025 (1 Nisan 2025), bu tarihi kurumlar vergisi mükellefleri için 1 Ocak 2026'ya, diğerleri için 1 Temmuz 2026'ya kaydırdı. Gerekçe somuttu: teknik düzenleme olan Orden HAC/1177/2024 ancak 28 Ekim 2024'te yayımlanmıştı.
• Real Decreto-ley 15/2025 (2 Aralık 2025), iki tarihi de bir yıl öteledi. Metni BOE'de yer alıyor ve Kongre kararnameyi aynı ay onayladı.

AEAT'nin en son 13 Ekim 2026'da güncellenen süre uzatımına ilişkin notu hiçbir tereddüde yer bırakmıyor: “las entidades que presenten el Impuesto sobre Sociedades deberán tener adaptados sus SIF antes del 1 de enero de 2027. El resto de obligados tributarios, antes del 1 de julio de 2027.”

Tarih yeniden değişebilir mi? Maliye Bakanlığı değişeceğini söylüyor. Bakanlığın 5 Ekim 2026 tarihli bilgi notu (nota informativa), RD 1007/2023'ten kaynaklanan ve henüz uygulanmaya başlamamış yükümlülüklerin, yıllık cirosu 8 milyon avroya kadar olan işletmeler için zorunlu e-Fatura ile aynı zamana denk gelecek şekilde “hasta octubre de 2028” erteleneceğini duyuruyor. Bu bir duyuru, mevzuat değişikliği değil. Not bir ay belirtiyor ama gün vermiyor, değişikliğin hangi düzenlemeyle yapılacağını söylemiyor ve şirketlerle serbest çalışanlar arasında bir ayrım yapmıyor. 16 Ekim 2026 itibarıyla BOE'de hiçbir şey yayımlanmadı ve AEAT'nin sayfaları hâlâ 2027 tarihlerini veriyor. Son dakikada gelen bir düzenleme alışılmadık olmaz: Real Decreto-ley 15/2025, ertelediği tarihten dört hafta önce, 3 Aralık 2025'te yayımlanmıştı. Not ayrıca bütünlük, izlenebilirlik ve değiştirilemezlik gerekliliklerinin “en términos sustancialmente equivalentes” korunacağını, kapsamın ve bazı teknik noktaların ise e-Fatura ve ViDA ile uyum sağlamak üzere daha sonra gözden geçirileceğini belirtiyor.

Sizin tarihiniz hangisi? Bir SL ya da SA, Impuesto sobre Sociedades beyannamesi verir; dolayısıyla kendi ERP'sini çalıştıran bir şirket neredeyse kesinlikle 1 Ocak 2027 tarihine tabidir. BOE'de aksini söyleyen bir düzenleme çıkana kadar bu tarih bağlayıcıdır ve on iki haftadan az bir süre kaldı. Temmuz tarihi serbest çalışanlar ve kapsamdaki diğer mükellefler içindir.

Nottaki Ekim 2028 tarihi, saati artık işlemeye başlamış ayrı bir düzenlemeden geliyor. 5 Ekim 2026'da BOE'de yayımlanan ve 6 Ekim'den beri yürürlükte olan Orden HAC/1028/2026, AEAT'nin kamuya açık e-Fatura çözümünü düzenliyor ve işletmeler arası e-Fatura zorunluluğunu getiren Real Decreto 238/2026'nın sürelerini başlatıyor: önceki yıl cirosu 8 milyon avroyu aşan işletmeler için on iki ay, diğerleri için yirmi dört ay. Böylece işletmeler arasındaki yapılandırılmış e-Faturalar Ekim 2027'de ve Ekim 2028'de zorunlu hâle geliyor. Başka işletmelere fatura kesen size özel bir sistemin önünde, VERI*FACTU'ya ne olursa olsun, bu proje de duruyor. Bu zorunluluğu İspanya'da B2B e-Fatura rehberimizde ele alıyoruz.

Kimler Kapsamda, Kimler Değil

AEAT'nin kapsam SSS'si bunu dört olumsuz koşula indiriyor. Faturalarınızı yalnızca elle düzenlemiyorsanız, SII'de (zorunlu olarak ya da kendi tercihinizle) değilseniz, vergi ikametgâhınız Bask Bölgesi'nde ya da Navarra'da değilse ve bir muafiyet kararınız yoksa kapsamdasınız.

Uygulamada istisnalar şunlar:

• SII'ye bildirim yapanlar. Suministro Inmediato de Información; cirosu 6 milyon avronun üzerindeki şirketler, KDV grupları ve aylık KDV iadesi siciline (REDEME) kayıtlı işletmeler için zorunludur, diğerleri de isteğe bağlı olarak katılabilir. AEAT bunu açıkça söylüyor: “El ámbito subjetivo de ambos proyectos es excluyente.” SII'ye geçerseniz VERI*FACTU kaydı göndermeyi ve QR kod basmayı bırakırsınız.
• Bask Bölgesi ve Navarra. Vergi ikametgâhı burada olan işletmeler RD 1007/2023'e değil, foral vergi idarelerine ve onların kendi kurallarına tabidir.
• Tamamen elle yapılan faturalama. Kâğıt fatura defteri kapsam dışıdır. Yalnızca faturaları yazmak, yazdırmak ve saklamak için kullanılan bir elektronik tablo da öyle; KDV defterlerinizi de üreten bir tablo ise kapsam dışı değildir.

İspanya'da daimi işyeri olan yabancı şirketler kapsamdadır.

Faturalarınızı ticari bir paketten (A3, Sage, Holded ve benzerleri) düzenliyorsanız üretici yazılım sağlayıcısıdır ve kendi beyanıyla birlikte uyarlanmış bir sürüm sunmak zorundadır. Paketi güncelleyin, beyanın orada olduğunu kontrol edin; okumayı burada bırakabilirsiniz.

Bu yazı geri kalanlar için: size özel bir ERP, on beş yıl önce yazılmış bir Access, Delphi ya da FileMaker programı veya kendi web platformunuzun içindeki bir faturalama modülü.

Üretici Sizin Şirketiniz

Yönetmeliğin 13.1 maddesi, sertifikasyonu bir declaración responsable (sorumluluk beyanı) aracılığıyla sistemi üreten kişiye yüklüyor. AEAT'nin sertifikasyon SSS'si şirket içinde geliştirilen yazılım durumunu doğrudan yanıtlıyor: “Cada sistema en operación debe disponer de una Certificación emitida mediante declaración responsable de su productor (artículo 13.1 RRSIF). Si el software hubiera sido desarrollado por la propia empresa, será esta la que deba certificarlo.”

Bunun pratikteki anlamı:

• Dış denetim yok. AEAT buna üreticinin “auto-certificación” (öz sertifikasyon) işlemi diyor. Sisteminizi kimse önceden onaylamıyor. Siz imzalıyorsunuz ve bundan siz sorumlusunuz.
• Sizin için bir eklentiyi ürün olarak geliştiren yüklenici, o eklentiyi kendisi sertifikalandırır. Eklentiyi siz geliştirdiyseniz sertifikalandıran da sizsiniz.
• Beyan her sürümde sistemin içinde görünür olmalı, ayrıca üründen bağımsız olarak sistemin dışından da erişilebilir olmalıdır.
• İçeriği sabittir. Orden HAC/1177/2024'ün 15. maddesine göre beyanda diğerlerinin yanı sıra sistemin adı, tanımlayıcısı ve sürümü, bileşenleri, yalnızca VERI*FACTU modunda çalışıp çalışmadığı, üreticinin adı, NIF'i ve adresi, imza tarihi ve yeri yer alır.

Zor olan durum, yazarı yıllar önce ayrılmış programdır. Uyarlanmış sürümü birinin yine de üretmesi ve imzalaması gerekiyor. İş başlamadan önce bunun kim olacağına karar verin ve yazılı hâle getirin.

Sertifikalı bir ticari ürünü özelleştirmek, ancak değişiklik yönetmelik gerekliliklerinin nasıl uygulandığına dokunuyorsa ayrı bir beyan gerektirir. Üreticinin kontrolü dışında yapılan ve bu gereklilikleri değiştirebilecek bir değişiklik ise uyumlu değildir.

Riskin boyutunu Genel Vergi Kanunu'nun (Ley General Tributaria) 201 bis maddesi belirliyor: gereklilikleri karşılamayan sistemler üretmek için mali yıl ve sistem türü başına 150.000 avro sabit para cezası; sertifikalı olması gerektiği hâlde olmayan ya da değiştirilmiş bir sisteme sahip olmak için mali yıl başına 50.000 avro. Kendi geliştirdiğiniz bir sistemin bunlardan hangisine tabi olacağı, vergi danışmanınıza sormanız gereken bir soru. İki rakam da küçük değil.

Yazılımın Yapması Gerekenler

Her fatura için, düzenlendiği anda bir kayıt

Madde 9.1, sistemin bir fatura kaydını (registro de facturación de alta) “de forma simultánea o inmediatamente anterior a la expedición de cada factura” oluşturmasını şart koşuyor. İptal edilen bir fatura için bir iptal kaydı (registro de anulación) oluşturulur.

Kaydın içeriğini 10. madde sıralıyor: düzenleyenin NIF'i ve adı, gerektiğinde alıcı, seri ve numara, düzenleme ve işlem tarihleri, fatura türü, düzelttiği bir fatura varsa onun bilgileri, bir açıklama, toplam tutar, KDV rejimi, matrah, oranlar ve tutarlar, muafiyet ya da vergi dışı kalma gerekçeleri, sistemin ve üreticisinin kimliği ve saniye hassasiyetinde bir zaman damgası.

Eski sistemlerde asıl iş burada saklı:

• KDV dökümleri çoğu zaman yazdırma anında hesaplanır ve hiç saklanmaz. Düzenleme anında veri olarak var olmaları gerekir.
• “Düzenlemek” çoğu zaman yalnızca bir rapor yazdırmaktan ibarettir. Bir taslağın faturaya dönüştüğü açık bir an olmalı ve kayıt o anda oluşturulmalıdır.
• Numaraları yeniden kullanma dönemi bitti. Pek çok küçük sistemde alışkanlık olan, bir faturayı silip numarasını yeniden kullanma pratiği artık işe yaramıyor: AEAT ikinci kaydı “Registro de facturación duplicado.” hatasıyla reddeder. Canlı ortamda düzenlenen test faturaları gerçek faturalardır ve iptal edilmeleri gerekir.
• Kimse kayıtları düzenlemez. AEAT'nin SSS'sine göre düzenlenmiş kayıtların veritabanında doğrudan değişiklik yapmak izin verilen bir işlem olmamalıdır. Personeliniz bugün faturaları SQL ile düzeltiyorsa bu sona erer. Düzeltmeler düzeltme faturalarıyla yapılır.

Hash zinciri

Her kayıt, bir önceki kaydın serisini, numarasını ve tarihini, ayrıca hash'inin (huella) bir kısmını taşır. Algoritma SHA-256'dır; tam alanlar ve birleştirme kuralları, kayıt tasarımları, XSD şemaları, WSDL ile doğrulama ve hata kataloğuyla birlikte AEAT'nin teknik dokümantasyonunda yer alır.

Yeni bir kayıt oluşturmadan önce sistem, son kaydın doğru zincirlendiğini ve zaman damgasının şu anki zamandan bir dakikadan fazla ileride olmadığını kontrol etmelidir. Kayıtlar, faturaların düzenlenme sırasına göre oluşturulur.

Bunun mimari bir sonucu var. Her kurulumun, kayıtların oluşturulduğu tek ve sıralı (serileştirilmiş) bir noktaya ihtiyacı vardır. Aynı zincire koordinasyon olmadan ekleme yapan iki web sunucusu zinciri bozar. AEAT karma yapıları kabul eder (örneğin kaydı merkezi bir arka ofisten alan POS terminalleri), ancak zincirin kendisi tek bir yerde durur.

Her sistem, mükellefin NIF'i, iki karakterli bir sistem kimliği ve aynı yazılım aynı makineye yeniden kurulsa bile asla tekrarlanamayacak bir kurulum numarasıyla tanımlanır.

Faturadaki QR kod

Her fatura, ISO/IEC 18004'e uygun, 30x30 ile 40x40 mm arasında ve M düzeyinde hata düzeltmeli bir QR kod taşır. Kod; düzenleyenin NIF'ini, seri ve numarayı, düzenleme tarihini ve toplam tutarı içeren, müşterinin AEAT üzerinden doğrulayabileceği bir URL'yi kodlar. VERI*FACTU modunda faturada ayrıca “VERI*FACTU” ya da “Factura verificable en la sede electrónica de la AEAT” ibaresi yer alır.

Eski yazılımlar için bu, fatura şablonunu (bir Access raporu, bir FileMaker düzeni, bir PDF üreteci) yeniden elden geçirmek ve hiç QR kütüphanesi olmamış bir teknoloji yığınına bir QR kütüphanesi eklemek demektir.

İki mod: VERI*FACTU ya da değil

VERI*FACTU modu. Sistem her kaydı, oluşturulduğu anda otomatik olarak AEAT'ye gönderir. Bunun karşılığında kayıtlar hash gerektirir ama elektronik imza gerektirmez, kayıtları AEAT saklar ve yalnızca bu modda çalışan bir sistemin olay günlüğüne ihtiyacı olmaz. AEAT'nin yayımladığı servislere bağlanan bir SOAP istemcisine, nitelikli bir elektronik sertifikaya ve bağlantı koptuğunda devreye girecek bir kuyruğa ihtiyacınız var. AEAT'nin geliştirici SSS'si kesintiyi bir olay olarak ele alır: kayıtlar kuyrukta bekler ve yeniden denenir, faturalama devam eder.

VERI*FACTU dışı mod. Kayıtlar sizde kalır ve her birinin nitelikli bir sertifikayla imzalanması gerekir (XAdES Enveloped, ETSI EN 319 132). Sistem ayrıca bu moddaki başlatma ve durdurmaları, anormallik kontrollerini ve bulgularını, yedekten geri yüklemeleri ve dışa aktarımları kapsayan, her altı saatlik çalışmada en az bir özet olay içeren imzalı bir olay günlüğü tutmalı ve AEAT istediğinde kayıtları teslim etmelidir.

Size özel bir sistem için yalnızca VERI*FACTU modu genellikle daha küçük bir geliştirme işidir. İmza altyapısı yok, olay günlüğü yok, anormallik araçları yok. Her iki modu da sunan bir sistemin bunların hepsini uygulaması gerekir.

Tarih Belirsizken Bir Plan

Duyurulan tarihe göre değil, yasal tarihe göre plan yapın. Ekim ortasından itibaren bir kurumlar vergisi mükellefinin yaklaşık on bir haftası var; aşağıdaki işler için bu dar bir süre. Bakanlık temel gerekliliklerin büyük ölçüde eşdeğer kalacağını söylediğinden, sonunda hangi tarih uygulanırsa uygulansın 1 ile 6 arasındaki adımlar aynı iştir. Bir ertelemenin değiştireceği şey 7. adımdır.

1. 1. hafta: envanter. Fatura düzenleyen her sistemi listeleyin: ERP, web mağazasının faturalama modülü, abonelik betiği, tezgâh terminali. SII'de olmadığınızı ve foral kurallara tabi olmadığınızı teyit edin.
2. 1-2. haftalar: kimin imzalayacağına ve hangi modu kullanacağınıza karar verin. Her sistem için üreticiyi belirleyin. Aksi için bir nedeniniz yoksa yalnızca VERI*FACTU modunu seçin. Şirketin nitelikli sertifikasının var olduğundan ve bir sorumlusu bulunduğundan emin olun; çünkü AEAT'nin geliştirici SSS'sine göre sistem sertifika olmadan çalışamaz.
3. 2-4. haftalar: veri boşluğu analizi. Sisteminizin sakladığı verileri 10. madde ve AEAT'nin kayıt tasarımıyla karşılaştırın. Eksik KDV dökümleri, fatura türü kodları ve düzeltme referansları burada ortaya çıkar.
4. 3-8. haftalar: geliştirme. Düzenleme anında kayıt oluşturma, zincir ve kontrolleri, değiştirilemez depolama, iptal, her şablonda QR kod ve yeniden deneme kuyruğuyla birlikte gönderim istemcisi. Düzenlenmiş kayıtlarda doğrudan değişiklik yapma imkânını kaldırın.
5. 6-10. haftalar: test. AEAT'nin test ortamında başlayın, ardından gerçek kayıtlar gönderin. AEAT son tarihinizden önceki süreyi bir test dönemi olarak kabul eder; bu dönemde göndermeyi durdurup başka bir sisteme geri dönebilirsiniz. İptal ve düzeltme akışlarını yazmadan önce geliştirici SSS'sini okuyun: uç durumların çoğunu kapsıyor.
6. 9-12. haftalar: beyan ve eğitim. Sorumluluk beyanını (declaración responsable) yazın, uygulamanın içinde ve dışında gösterin ve sürümü kayda geçirin. Finans ekibine numaraların asla yeniden kullanılmadığını ve hataların düzeltme faturalarıyla giderildiğini anlatın.
7. Aralık ortası: canlıya geçiş. “antes del 1 de enero” diye yazılmış bir son tarih, canlıya geçiş tarihi değildir. İlk sorunlar hâlâ zaman varken ortaya çıksın diye iki hafta erken canlıya geçin. O zamana kadar tarihi erteleyen bir düzenleme BOE'de yayımlanmışsa ileri alınacak adım budur.

1 Temmuz 2027 tarihi için de aynı plan geçerli, yalnızca daha fazla zamanınız var. Mayısta değil, ocakta başlayın.

Yeniden geliştirmeye karşı dürüstçe tartılmaya değer iki alternatif var. AEAT karma mimarileri kabul ettiği için ERP'niz fatura verilerini hazırlamaya devam ederken satın alınmış ya da geliştirilmiş ayrı bir bileşen kayıtları, QR kodu ve gönderimi üstlenebilir; yeter ki beyanlar parçaların birbirine nasıl bağlandığını kapsasın. Eski program ayda yalnızca birkaç fatura düzenliyorsa AEAT'nin küçük işletmeler için ücretsiz faturalama uygulaması ya da standart bir paket, onu uyarlamaktan daha ucuza gelebilir.

Nereden Destek Alabilirsiniz

Şirketlerin halihazırda çalıştırdığı faturalama kodunu, eski teknoloji yığınları dahil, değiştiriyoruz: kayıt oluşturma, hash zinciri, şablonlarınızdaki QR kod ve AEAT gönderim istemcisi; geride testleriyle birlikte. e-Fatura entegrasyonu hizmetimiz geliştirmenin kendisini kapsar; eski programın nasıl çalıştığını bilen kimse kalmadıysa iş eski sistem bakımı ile başlar.

1 Ocak 2027 tarihine tabiyseniz ve size özel bir sisteminiz varsa office@c9group.dev adresine yazın. Biz vergi danışmanı değil, mühendisiz: kapsam ve sorumluluk soruları sizin danışmanınızın alanı; biz onların verdiği yanıta göre geliştiririz.