VERI*FACTU en maatwerk-factureringssoftware: wat Spanje uiterlijk 1 januari 2027 eist

Vóór 1 januari 2027 moet elk bedrijf in Spanje dat vennootschapsbelasting (Impuesto sobre Sociedades) aangeeft en met software factureert, software gebruiken die is aangepast aan Real Decreto 1007/2023. Elke factuur krijgt een gehasht record dat aan het vorige is gekoppeld, en een QR-code die de klant bij de Spaanse belastingdienst kan controleren. Alle anderen die eronder vallen, vooral zelfstandigen, hebben tot 1 juli 2027.

Komen uw facturen uit een commercieel pakket, dan is dit grotendeels het werk van uw leverancier. Komen ze uit software die iemand voor u heeft geschreven, of die uw eigen team heeft geschreven, dan is het uw werk. U past de code aan, en u ondertekent de verklaring dat ze voldoet.

De data, en de twee keer uitstel

Dit is de derde set data, dus enige scepsis is terecht.

• Real Decreto 1007/2023 gaf bedrijven oorspronkelijk tot 1 juli 2025.
• Real Decreto 254/2025 van 1 april 2025 verschoof dat naar 1 januari 2026 voor vennootschapsbelastingplichtigen en 1 juli 2026 voor de rest. De reden was concreet: de technische regeling, Orden HAC/1177/2024, verscheen pas op 28 oktober 2024.
• Real Decreto-ley 15/2025 van 2 december 2025 verschoof beide data met een jaar. De tekst staat in het BOE, en het Congres bekrachtigde het decreet dezelfde maand.

De toelichting van de AEAT op de verlenging, bijgewerkt op 26 maart 2026, laat geen ruimte voor twijfel: “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.”

Kan het opnieuw verschuiven? Per oktober 2026 zegt niets officieels dat. Het eerste uitstel had een technische oorzaak die niet meer bestaat. De indieningsdiensten van de AEAT draaien sinds 23 april 2025 in productie, en sinds 29 juli 2025 mogen softwareleveranciers alleen nog aangepaste systemen aanbieden. Rekenen op een derde uitstel is een gok, geen plan.

Welke datum is de uwe? Een SL of SA geeft Impuesto sobre Sociedades aan, dus een bedrijf met een eigen ERP-systeem zit vrijwel zeker op de datum van 1 januari 2027. Dat is minder dan drie maanden weg. De julidatum is voor zelfstandigen en de andere belastingplichtigen die eronder vallen.

Wie eronder valt, en wie niet

De FAQ van de AEAT over de reikwijdte brengt het terug tot vier ontkenningen. U valt eronder als u niet uitsluitend met de hand factureert, niet in het SII zit (verplicht of vrijwillig), uw fiscale woonplaats niet in Baskenland of Navarra hebt en geen vrijstellingsbeschikking hebt.

De uitzonderingen, in de praktijk:

• SII-aangevers. Het Suministro Inmediato de Información is verplicht voor bedrijven met een omzet boven € 6 miljoen, btw-groepen en bedrijven in het register voor maandelijkse btw-teruggaaf (REDEME), en anderen kunnen er vrijwillig voor kiezen. De AEAT zegt het onomwonden: “El ámbito subjetivo de ambos proyectos es excluyente.” Stapt u over naar het SII, dan stopt u met het versturen van VERI*FACTU-records en met het afdrukken van de QR-code.
• Baskenland en Navarra. Bedrijven met hun fiscale woonplaats daar vallen onder de forale belastingdiensten en hun eigen regels, niet onder RD 1007/2023.
• Puur handmatige facturering. Een papieren factuurboek valt erbuiten. Een spreadsheet die alleen wordt gebruikt om facturen te typen, te printen en te bewaren ook; een spreadsheet die daarnaast uw btw-boeken aanmaakt, niet.

Buitenlandse bedrijven vallen eronder als ze een vaste inrichting in Spanje hebben.

Factureert u vanuit een commercieel pakket (A3, Sage, Holded en dergelijke), dan is de leverancier de producent en moet die een aangepaste versie met een eigen verklaring leveren. Werk het pakket bij, controleer of de verklaring erin staat, en u kunt hier stoppen met lezen.

Dit artikel is voor de rest: een maatwerk-ERP, een Access-, Delphi- of FileMaker-programma van vijftien jaar geleden, of een factureringsmodule in uw eigen webplatform.

Uw bedrijf is de producent

Artikel 13.1 van de regeling legt de certificering bij degene die het systeem produceert, door middel van een declaración responsable (een verklaring op eigen verantwoordelijkheid). De FAQ van de AEAT over certificering behandelt het geval van eigen ontwikkeling rechtstreeks: “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.”

Wat dat in de praktijk betekent:

• Er is geen externe audit. De AEAT noemt het een “auto-certificación” van de producent. Niemand keurt uw systeem vooraf goed. U tekent, en u staat ervoor in.
• Een opdrachtnemer die voor u een uitbreiding als product bouwt, certificeert die uitbreiding. Hebt u haar zelf gebouwd, dan certificeert u haar zelf.
• De verklaring moet in elke versie binnen het systeem zichtbaar zijn, en daarnaast ook daarbuiten bereikbaar, los van het product.
• De inhoud ligt vast in artikel 15 van Orden HAC/1177/2024: onder meer de naam, identificatie en versie van het systeem, de onderdelen ervan, of het uitsluitend in VERI*FACTU-modus werkt, de naam, het NIF en het adres van de producent, en de datum en plaats van ondertekening.

Het lastige geval is het programma waarvan de auteur jaren geleden is vertrokken. Iemand moet nog steeds de aangepaste versie maken en ervoor tekenen. Leg schriftelijk vast wie dat is voordat het werk begint.

Aanpassingen aan een gecertificeerd commercieel product vragen alleen een aparte verklaring als de wijziging raakt aan de manier waarop de eisen van de regeling zijn geïmplementeerd. Een wijziging buiten de controle van de producent die die eisen kan aantasten, voldoet niet.

Wat er op het spel staat, regelt artikel 201 bis van de Ley General Tributaria: een vaste boete van € 150.000 per boekjaar en per type systeem voor het produceren van systemen die niet aan de eisen voldoen, en € 50.000 per boekjaar voor het bezitten van een systeem dat gecertificeerd zou moeten zijn en dat niet is, of dat is gewijzigd. Welke van de twee een zelfgebouwd systeem zou treffen, is een vraag voor uw belastingadviseur. Geen van beide bedragen is klein.

Wat de software moet doen

Een record voor elke factuur, op het moment van uitreiken

Artikel 9.1 eist dat het systeem een registro de facturación de alta aanmaakt “de forma simultánea o inmediatamente anterior a la expedición de cada factura”. Een vervallen factuur krijgt een annuleringsrecord (registro de anulación).

Artikel 10 somt op wat het record bevat: NIF en naam van de uitgever, de ontvanger waar dat vereist is, reeks en nummer, uitgifte- en transactiedatum, factuurtype, gegevens van een eventuele gecorrigeerde factuur, een omschrijving, het totaal, het btw-regime, de maatstaf van heffing, tarieven en bedragen, redenen voor vrijstelling of niet-belastbaarheid, de identiteit van het systeem en van de producent, en een tijdstempel tot op de seconde.

In oudere systemen zit hier het verborgen werk:

• Btw-uitsplitsingen worden vaak pas bij het afdrukken berekend en nooit opgeslagen. Ze moeten op het moment van uitreiken als data bestaan.
• “Uitreiken” is vaak niet meer dan een rapport afdrukken. Er moet een expliciet moment zijn waarop een concept een factuur wordt, en op dat moment wordt het record aangemaakt.
• Nummers hergebruiken is voorbij. Een factuur verwijderen en het nummer opnieuw gebruiken, in veel kleine systemen een gewoonte, mislukt nu: de AEAT weigert het tweede record met “Registro de facturación duplicado.” Testfacturen die in productie zijn uitgereikt, zijn echte facturen en moeten worden geannuleerd.
• Niemand bewerkt records. De FAQ van de AEAT zegt dat directe wijzigingen in de database met uitgereikte records geen toegestane handeling mogen zijn. Corrigeren medewerkers vandaag facturen met SQL, dan houdt dat op. Correcties lopen via corrigerende facturen.

De hashketen

Elk record bevat de reeks, het nummer en de datum van het vorige record en een deel van diens hash (huella). Het algoritme is SHA-256, en de precieze velden en de aaneenschakeling staan in de technische documentatie van de AEAT, samen met de recordontwerpen, XSD-schema's, de WSDL en de catalogus van validaties en foutcodes.

Voordat het systeem een nieuw record aanmaakt, moet het controleren of het laatste record correct is gekoppeld en of de tijdstempel daarvan niet meer dan een minuut later ligt dan de huidige tijd. Records worden aangemaakt in de volgorde waarin facturen worden uitgereikt.

Dat heeft gevolgen voor de architectuur. Elke installatie heeft één geserialiseerd punt nodig waar records worden aangemaakt. Twee webservers die zonder coördinatie aan dezelfde keten toevoegen, breken haar. De AEAT accepteert gemengde opstellingen, zoals kassaterminals die het record van een centrale backoffice ontvangen, maar de keten zelf staat op één plek.

Elk systeem wordt geïdentificeerd met het NIF van de belastingplichtige, een systeem-ID van twee tekens en een installatienummer dat nooit mag terugkomen, ook niet als dezelfde software opnieuw op dezelfde machine wordt geïnstalleerd.

De QR-code op de factuur

Elke factuur draagt een QR-code volgens ISO/IEC 18004, tussen 30x30 en 40x40 mm, met foutcorrectieniveau M. Die codeert een URL met het NIF van de uitgever, de reeks en het nummer, de uitgiftedatum en het totaal, die de klant bij de AEAT kan controleren. In VERI*FACTU-modus vermeldt de factuur daarnaast “VERI*FACTU” of “Factura verificable en la sede electrónica de la AEAT”.

Voor legacysoftware betekent dit het factuursjabloon ombouwen (een Access-rapport, een FileMaker-lay-out, een pdf-generator) en een QR-bibliotheek toevoegen aan een stack die er nooit een had.

Twee modi: VERI*FACTU of niet

VERI*FACTU-modus. Het systeem stuurt elk record automatisch naar de AEAT, op het moment dat het wordt aangemaakt. In ruil daarvoor hebben records een hash nodig maar geen elektronische handtekening, bewaart de AEAT ze, en heeft een systeem dat alleen in deze modus werkt geen gebeurtenissenlog nodig. U hebt een SOAP-client nodig voor de gepubliceerde diensten van de AEAT, een gekwalificeerd elektronisch certificaat en een wachtrij voor als de verbinding wegvalt. De FAQ voor ontwikkelaars van de AEAT behandelt een storing als een incident: records wachten in de wachtrij en worden opnieuw verstuurd, en het factureren gaat door.

Niet-VERI*FACTU-modus. Records blijven bij u, en elk record moet worden ondertekend (XAdES Enveloped, ETSI EN 319 132) met een gekwalificeerd certificaat. Het systeem moet bovendien een ondertekend gebeurtenissenlog bijhouden van het starten en stoppen in deze modus, van anomaliecontroles en wat die vinden, van het terugzetten van back-ups en van exports, met minstens elke zes uur gebruik een samenvattende gebeurtenis, en het moet records overdragen wanneer de AEAT daarom vraagt.

Voor een maatwerksysteem is alleen VERI*FACTU meestal de kleinere bouw. Geen ondertekeningsinfrastructuur, geen gebeurtenissenlog, geen tooling voor anomalieën. Een systeem dat beide modi aanbiedt, moet dat allemaal implementeren.

Een plan dat vóór 1 januari 2027 past

Vanaf begin oktober heeft een vennootschapsbelastingplichtige ongeveer dertien weken. Dit is de volgorde die werkt.

1. Week 1: inventarisatie. Maak een lijst van elk systeem dat facturen uitreikt: het ERP-systeem, de factureringsmodule van de webwinkel, het abonnementsscript, de toonbankterminal. Bevestig dat u niet in het SII zit en niet onder forale regels valt.
2. Week 1 tot 2: beslis wie tekent en welke modus. Wijs voor elk systeem de producent aan. Kies alleen VERI*FACTU, tenzij u een reden hebt om dat niet te doen. Zorg dat het gekwalificeerde certificaat van het bedrijf bestaat en dat iemand er eigenaar van is, want volgens de FAQ voor ontwikkelaars van de AEAT kan het systeem zonder certificaat niet werken.
3. Week 2 tot 4: analyse van ontbrekende data. Vergelijk wat uw systeem opslaat met artikel 10 en het recordontwerp van de AEAT. Ontbrekende btw-uitsplitsingen, codes voor factuurtypen en verwijzingen naar gecorrigeerde facturen komen hier boven.
4. Week 3 tot 8: bouwen. Aanmaken van records bij uitreiken, de keten en haar controles, onveranderbare opslag, annulering, de QR-code op elk sjabloon, en de indieningsclient met zijn wachtrij voor nieuwe pogingen. Verwijder directe bewerkingen van uitgereikte records.
5. Week 6 tot 10: testen. Begin in de testomgeving van de AEAT en stuur daarna echte records. De AEAT behandelt de tijd vóór uw deadline als testperiode, waarin u mag stoppen met versturen en mag terugvallen op een ander systeem. Lees de FAQ voor ontwikkelaars voordat u de stromen voor annulering en correctie schrijft: daarin staan de meeste randgevallen.
6. Week 9 tot 12: verklaren en trainen. Stel de declaración responsable op, toon haar in de applicatie en daarbuiten, en leg de versie vast. Vertel de financiële afdeling dat nummers nooit worden hergebruikt en dat fouten worden hersteld met corrigerende facturen.
7. Half december: livegang. Een deadline die “antes del 1 de enero” luidt, is geen livedatum. Ga twee weken eerder live, zodat de eerste problemen opduiken terwijl er nog tijd is.

Voor de datum van 1 juli 2027 geldt hetzelfde plan, met meer ruimte. Begin in januari, niet in mei.

Twee alternatieven voor herbouwen verdienen een eerlijke afweging. De AEAT accepteert gemengde architecturen, dus uw ERP-systeem kan factuurgegevens blijven voorbereiden terwijl een apart onderdeel, gekocht of gebouwd, de records, de QR-code en de indiening verzorgt, mits de verklaringen beschrijven hoe de delen op elkaar aansluiten. En reikt het oude programma een handvol facturen per maand uit, dan kost de gratis factureringsapplicatie van de AEAT voor kleine bedrijven, of een standaardpakket, misschien minder dan het aanpassen.

Waar u hulp krijgt

Wij passen factureringscode aan die bedrijven al draaien, ook op oudere stacks: het aanmaken van records, de hashketen, de QR-code op uw sjablonen en de indieningsclient voor de AEAT, met tests die achterblijven. Onze dienst voor e-facturatie-integratie dekt de bouw, en onderhoud van legacysystemen is waar het begint als niemand meer weet hoe het oude programma werkt.

Hebt u een deadline van 1 januari 2027 en een maatwerksysteem, schrijf dan naar office@c9group.dev. Wij zijn ingenieurs, geen belastingadviseurs: vragen over reikwijdte en aansprakelijkheid horen bij die van u, en wij bouwen naar het antwoord dat zij geven.