VERI*FACTU og specialudviklet faktureringssoftware: hvad Spanien kræver senest 1. januar 2027

Inden 1. januar 2027 skal alle virksomheder i Spanien, der indgiver selskabsskatteangivelse (Impuesto sobre Sociedades) og fakturerer fra software, bruge software, der er tilpasset Real Decreto 1007/2023. Hver faktura får en hashet registrering, der er kædet sammen med den foregående, og en QR-kode, som kunden kan tjekke hos skattemyndigheden. Alle andre omfattede, primært selvstændige, har frist til 1. juli 2027.

Kommer jeres fakturaer ud af en standardpakke, er det i det store hele leverandørens opgave. Kommer de ud af software, som nogen har skrevet til jer, eller som jeres eget team har skrevet, er det jeres. I ændrer koden, og I underskriver den erklæring, der siger, at den overholder reglerne.

Datoerne og de to udskydelser

Dette er tredje sæt datoer, så en vis skepsis er rimelig.

• Real Decreto 1007/2023 gav oprindeligt virksomhederne frist til 1. juli 2025.
• Real Decreto 254/2025 af 1. april 2025 flyttede den til 1. januar 2026 for selskabsskatteydere og 1. juli 2026 for resten. Grunden var konkret: den tekniske bekendtgørelse, Orden HAC/1177/2024, blev først offentliggjort 28. oktober 2024.
• Real Decreto-ley 15/2025 af 2. december 2025 flyttede begge datoer et år. Teksten findes i BOE, og Kongressen godkendte den samme måned.

AEAT's meddelelse om fristforlængelsen, opdateret 26. marts 2026, er utvetydig: »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.« Selskabsskatteydere skal altså have tilpasset deres faktureringssystemer (SIF) inden 1. januar 2027, og øvrige skattepligtige inden 1. juli 2027.

Kan datoen flytte sig igen? Intet officielt peger på det i oktober 2026. Den første udskydelse havde en teknisk årsag, som ikke længere findes. AEAT's indberetningstjenester har været i produktion siden 23. april 2025, og siden 29. juli 2025 må softwareleverandører kun tilbyde tilpassede systemer. At planlægge efter en tredje udskydelse er et væddemål, ikke en plan.

Hvilken dato er jeres? Et SL eller SA indgiver Impuesto sobre Sociedades, så en virksomhed med sit eget ERP-system er næsten med sikkerhed omfattet af 1. januar 2027. Det er mindre end tre måneder væk. Julidatoen gælder for selvstændige og de øvrige omfattede skattepligtige.

Hvem der er omfattet, og hvem der ikke er

AEAT's FAQ om anvendelsesområdet koger det ned til fire benægtelser. I er omfattet, hvis I ikke udelukkende fakturerer manuelt, ikke er med i SII (hverken tvunget eller frivilligt), ikke har skattemæssigt hjemsted i Baskerlandet eller Navarra og ikke har en afgørelse om fritagelse.

Undtagelserne i praksis:

• Virksomheder i SII. Suministro Inmediato de Información er obligatorisk for virksomheder med en omsætning over 6 millioner euro, momsgrupper og virksomheder i registret for månedlig momsrefusion (REDEME), og andre kan tilmelde sig frivilligt. AEAT siger det ligeud: »El ámbito subjetivo de ambos proyectos es excluyente.« De to ordninger udelukker altså hinanden. Går I over i SII, holder I op med at sende VERI*FACTU-registreringer og med at printe QR-koden.
• Baskerlandet og Navarra. Virksomheder med skattemæssigt hjemsted der hører under de forale skattemyndigheder og deres egne regler, ikke under RD 1007/2023.
• Rent manuel fakturering. En fakturabog på papir er ikke omfattet. Det er et regneark heller ikke, hvis det kun bruges til at skrive, printe og gemme fakturaer; et regneark, der også danner jeres momsbøger, er omfattet.

Udenlandske virksomheder er omfattet, når de har et fast driftssted i Spanien.

Fakturerer I fra en standardpakke (A3, Sage, Holded og lignende), er leverandøren producenten og skal levere en tilpasset version med sin egen erklæring. Opdatér den, tjek at erklæringen er der, og så kan I stoppe med at læse her.

Denne artikel er til resten: et specialudviklet ERP-system, et Access-, Delphi- eller FileMaker-program skrevet for femten år siden eller et faktureringsmodul i jeres egen webplatform.

Jeres virksomhed er producenten

Forordningens artikel 13.1 lægger certificeringen på den, der producerer systemet, i form af en declaración responsable (en erklæring på eget ansvar). AEAT's FAQ om certificering besvarer tilfældet med egenudviklet software direkte: »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.« Har virksomheden selv udviklet softwaren, er det altså virksomheden, der skal certificere den.

Hvad det betyder i praksis:

• Der er ingen ekstern revision. AEAT kalder det en »auto-certificación« fra producenten. Ingen godkender jeres system på forhånd. I underskriver, og I står til ansvar.
• En underleverandør, der bygger en udvidelse til jer som et produkt, certificerer den udvidelse. Har I bygget den selv, certificerer I den.
• Erklæringen skal være synlig inde i systemet, i hver version, og også kunne findes uden for det, uafhængigt af produktet.
• Indholdet er fastlagt i artikel 15 i Orden HAC/1177/2024: blandt andet systemets navn, identifikator og version, dets komponenter, om det kun fungerer i VERI*FACTU-tilstand, producentens navn, NIF og adresse samt dato og sted for underskriften.

Det akavede tilfælde er programmet, hvis forfatter forlod virksomheden for år tilbage. Nogen skal stadig producere den tilpassede version og skrive under på den. Beslut skriftligt, hvem det er, før arbejdet går i gang.

Tilpasning af et certificeret standardprodukt kræver kun en separat erklæring, hvis ændringen berører den måde, forordningens krav er implementeret på. En ændring, der foretages uden for producentens kontrol og kan påvirke kravene, overholder ikke reglerne.

Hvad der står på spil, fremgår af artikel 201 bis i den generelle skattelov: en fast bøde på 150.000 euro pr. regnskabsår og pr. systemtype for at producere systemer, der ikke opfylder kravene, og 50.000 euro pr. regnskabsår for at have et system, der burde være certificeret og ikke er det, eller som er blevet ændret. Hvilken af dem et egenudviklet system vil udløse, er et spørgsmål til jeres skatterådgiver. Ingen af beløbene er små.

Hvad softwaren skal kunne

En registrering for hver faktura, i det øjeblik den udstedes

Artikel 9.1 kræver, at systemet danner et registro de facturación de alta »de forma simultánea o inmediatamente anterior a la expedición de cada factura«, altså samtidig med eller umiddelbart før udstedelsen af hver faktura. En annulleret faktura får en annulleringsregistrering (registro de anulación).

Artikel 10 oplister, hvad registreringen indeholder: udstederens NIF og navn, modtageren hvor det kræves, serie og nummer, udstedelses- og transaktionsdato, fakturatype, oplysninger om en eventuel faktura, den retter, en beskrivelse, totalen, momsordningen, momsgrundlag, satser og beløb, årsager til fritagelse eller manglende momspligt, identiteten på systemet og dets producent samt et tidsstempel på sekundet.

I ældre systemer er det her, arbejdet gemmer sig:

• Momsopgørelser beregnes ofte i det øjeblik, fakturaen printes, og gemmes aldrig. De skal eksistere som data i udstedelsesøjeblikket.
• »Udstedelse« er ofte bare udskrivning af en rapport. Der skal være et udtrykkeligt punkt, hvor et udkast bliver til en faktura, og det er dér, registreringen oprettes.
• Genbrug af numre er slut. At slette en faktura og genbruge dens nummer, en vane i mange små systemer, fejler nu: AEAT afviser den anden registrering som »Registro de facturación duplicado.« Testfakturaer udstedt i produktion er rigtige fakturaer og skal annulleres.
• Ingen redigerer registreringer. Ifølge AEAT's FAQ må direkte ændringer i databasen med udstedte registreringer ikke være en tilladt handling. Retter medarbejderne fakturaer med SQL i dag, så stopper det. Rettelser sker via rettelsesfakturaer.

Hashkæden

Hver registrering indeholder serie, nummer og dato for den foregående registrering samt en del af dens hash (huella). Algoritmen er SHA-256, og de præcise felter og den præcise sammenkædning står i AEAT's tekniske dokumentation sammen med registreringsdesign, XSD-skemaer, WSDL og kataloget over valideringer og fejl.

Før en ny registrering dannes, skal systemet kontrollere, at den seneste er korrekt kædet, og at dens tidsstempel ikke ligger mere end ét minut efter det aktuelle tidspunkt. Registreringer dannes i den rækkefølge, fakturaerne udstedes.

Det har en arkitektonisk konsekvens. Hver installation har brug for ét enkelt, serialiseret sted, hvor registreringer oprettes. To webservere, der tilføjer til samme kæde uden koordinering, vil bryde den. AEAT accepterer blandede opsætninger, for eksempel kasseterminaler, der modtager registreringen fra et centralt backoffice, men selve kæden ligger ét sted.

Hvert system identificeres med den skattepligtiges NIF, et system-id på to tegn og et installationsnummer, der aldrig må gentages, heller ikke når samme software geninstalleres på samme maskine.

QR-koden på fakturaen

Hver faktura har en QR-kode efter ISO/IEC 18004 på mellem 30x30 og 40x40 mm med fejlkorrektionsniveau M. Den indeholder en URL med udstederens NIF, serie og nummer, udstedelsesdatoen og totalen, som kunden kan tjekke hos AEAT. I VERI*FACTU-tilstand skal fakturaen desuden angive »VERI*FACTU« eller »Factura verificable en la sede electrónica de la AEAT«.

For ældre software betyder det, at fakturaskabelonen skal laves om (en Access-rapport, et FileMaker-layout, en PDF-generator), og at der skal tilføjes et QR-bibliotek til en stak, der aldrig har haft et.

To tilstande: VERI*FACTU eller ej

VERI*FACTU-tilstand. Systemet sender automatisk hver registrering til AEAT, efterhånden som den dannes. Til gengæld kræver registreringerne en hash, men ingen elektronisk signatur, AEAT opbevarer dem, og et system, der kun fungerer i denne tilstand, behøver ingen hændelseslog. I har brug for en SOAP-klient mod AEAT's offentliggjorte tjenester, et kvalificeret elektronisk certifikat og en kø til de tidspunkter, hvor forbindelsen svigter. AEAT's FAQ for udviklere behandler et nedbrud som en hændelse: registreringerne venter i køen og sendes igen, og faktureringen fortsætter.

Ikke-VERI*FACTU-tilstand. Registreringerne bliver hos jer, og hver skal signeres (XAdES Enveloped, ETSI EN 319 132) med et kvalificeret certifikat. Systemet skal også føre en signeret hændelseslog, der dækker start og stop i denne tilstand, kontrol for uregelmæssigheder og deres resultater, gendannelse fra backup og eksport, med en opsummerende hændelse mindst for hver seks timers drift, og det skal udlevere registreringerne, når AEAT beder om dem.

For et specialudviklet system er ren VERI*FACTU som regel den mindste opgave. Ingen signeringsinfrastruktur, ingen hændelseslog, intet værktøj til uregelmæssigheder. Et system, der tilbyder begge tilstande, skal implementere det hele.

En plan, der kan nås før 1. januar 2027

Fra begyndelsen af oktober har en selskabsskatteyder omkring tretten uger. Dette er den rækkefølge, der virker.

1. Uge 1: overblik. List alle systemer, der udsteder fakturaer: ERP-systemet, webshoppens faktureringsmodul, abonnementsscriptet, terminalen ved disken. Bekræft, at I hverken er i SII eller under forale regler.
2. Uge 1 til 2: beslut, hvem der underskriver, og hvilken tilstand I bruger. Udpeg producenten for hvert system. Vælg ren VERI*FACTU, medmindre I har en grund til andet. Sørg for, at virksomhedens kvalificerede certifikat findes, og at nogen ejer det, for AEAT's FAQ for udviklere påpeger, at systemet ikke kan fungere uden.
3. Uge 2 til 4: analyse af datahuller. Sammenlign det, jeres system gemmer, med artikel 10 og AEAT's registreringsdesign. Manglende momsopgørelser, koder for fakturatype og henvisninger ved rettelser dukker op her.
4. Uge 3 til 8: udvikling. Dannelse af registreringer ved udstedelse, kæden og dens kontroller, uforanderlig lagring, annullering, QR-koden på hver skabelon og indberetningsklienten med dens kø til genforsøg. Fjern muligheden for direkte redigering af udstedte registreringer.
5. Uge 6 til 10: test. Start i AEAT's testmiljø, og send derefter rigtige registreringer. AEAT behandler tiden før jeres frist som en testperiode, hvor I kan stoppe afsendelsen og falde tilbage på et andet system. Læs FAQ'en for udviklere, før I skriver forløbene for annullering og rettelse: den dækker de fleste særtilfælde.
6. Uge 9 til 12: erklær og oplær. Skriv declaración responsable, vis den i applikationen og uden for den, og registrér versionen. Fortæl økonomiafdelingen, at numre aldrig genbruges, og at fejl rettes med rettelsesfakturaer.
7. Midt i december: go live. En frist, der lyder »antes del 1 de enero« (inden 1. januar), er ikke en go live-dato. Gå i drift fjorten dage før, så de første problemer viser sig, mens der stadig er tid.

For datoen 1. juli 2027 gælder samme plan med mere luft. Start i januar, ikke i maj.

To alternativer til at bygge om er værd at overveje ærligt. AEAT accepterer blandede arkitekturer, så jeres ERP-system kan fortsætte med at forberede fakturadata, mens en separat komponent, købt eller bygget, danner registreringerne, QR-koden og indberetningen, forudsat at erklæringerne dækker, hvordan delene hænger sammen. Og udsteder det gamle program en håndfuld fakturaer om måneden, kan AEAT's gratis faktureringsprogram til små virksomheder eller en standardpakke være billigere end at tilpasse det.

Hvor I kan få hjælp

Vi ændrer faktureringskode, som virksomheder allerede kører, også på ældre stakke: dannelse af registreringer, hashkæden, QR-koden på jeres skabeloner og indberetningsklienten til AEAT, med test, der bliver liggende bagefter. Vores service til integration af e-fakturering dækker udviklingen, og vedligeholdelse af ældre systemer er stedet at starte, når ingen tilbage i virksomheden ved, hvordan det gamle program virker.

Har I fristen 1. januar 2027 og et specialudviklet system, så skriv til office@c9group.dev. Vi er ingeniører, ikke skatterådgivere: spørgsmål om afgrænsning og ansvar hører hjemme hos jeres rådgiver, og vi bygger efter det svar, de giver.