VERI*FACTU och egenutvecklade fakturasystem: deadline 2027 och den aviserade flytten till 2028

Före 1 januari 2027 måste varje företag i Spanien som deklarerar bolagsskatt (Impuesto sobre Sociedades) och fakturerar med programvara använda programvara som är anpassad till Real Decreto 1007/2023. Varje faktura får en hashad post som är kedjad till den föregående, och en QR-kod som kunden kan kontrollera mot skattemyndigheten. Alla andra som omfattas, främst egenföretagare, har till 1 juli 2027. Den 5 oktober 2026 meddelade finansministeriet att skyldigheterna ska skjutas fram till oktober 2028. Den 16 oktober har ännu ingen författning med den innebörden publicerats, så datumen 2027 gäller fortfarande.

Kommer dina fakturor från ett kommersiellt standardprogram är det här till stor del leverantörens sak. Kommer de från programvara som någon har skrivit åt dig, eller som ditt eget team har skrivit, är det din sak. Du ändrar koden, och du skriver under försäkran om att den uppfyller kraven.

Datumen och de två uppskjutningarna

Det här är den tredje uppsättningen datum, så en viss skepsis är befogad.

• Real Decreto 1007/2023 gav ursprungligen företagen till 1 juli 2025.
• Real Decreto 254/2025 av den 1 april 2025 flyttade det till 1 januari 2026 för den som deklarerar bolagsskatt och till 1 juli 2026 för övriga. Skälet var konkret: den tekniska förordningen, Orden HAC/1177/2024, publicerades först den 28 oktober 2024.
• Real Decreto-ley 15/2025 av den 2 december 2025 flyttade båda datumen ett år. Texten finns i BOE, och kongressen godkände den (convalidación) samma månad.

AEAT:s meddelande om förlängningen, senast uppdaterat den 13 oktober 2026, lämnar inget utrymme för tvivel: ”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 datumet flyttas igen? Finansministeriet säger att det ska göra det. Dess nota informativa av den 5 oktober 2026 aviserar att de skyldigheter enligt RD 1007/2023 som ännu inte trätt i kraft skjuts upp ”hasta octubre de 2028”, så att de sammanfaller med obligatorisk e-fakturering för företag med en årsomsättning på upp till 8 miljoner euro. Det är ett besked, inte en lagändring. Meddelandet anger en månad men ingen dag, säger inte vilket rättsligt instrument som ska genomföra ändringen och skiljer inte mellan bolag och egenföretagare. Den 16 oktober 2026 har ingenting publicerats i BOE, och AEAT:s sidor anger fortfarande datumen 2027. En sen författning vore inget ovanligt: Real Decreto-ley 15/2025 publicerades den 3 december 2025, fyra veckor före det datum den flyttade. Meddelandet säger också att kraven på integritet, spårbarhet och oföränderlighet ska bestå ”en términos sustancialmente equivalentes”, och att tillämpningsområdet och vissa tekniska punkter ska ses över senare för att närma sig e-faktureringen och ViDA.

Vilket datum gäller dig? Ett SL eller SA deklarerar Impuesto sobre Sociedades, så ett bolag som kör ett eget affärssystem har nästan säkert datumet 1 januari 2027. Tills en författning i BOE säger något annat är det datumet bindande, och det är mindre än tolv veckor bort. Julidatumet gäller egenföretagare och övriga skattskyldiga som omfattas.

Oktober 2028 i meddelandet kommer från en annan reglering, vars klocka nu har börjat ticka. Orden HAC/1028/2026, publicerad i BOE den 5 oktober 2026 och i kraft sedan den 6 oktober, reglerar AEAT:s offentliga lösning för e-fakturering och startar fristerna i Real Decreto 238/2026, kravet på e-fakturering mellan företag: tolv månader för företag vars omsättning översteg 8 miljoner euro föregående år, tjugofyra månader för övriga. Strukturerade e-fakturor mellan företag blir därmed obligatoriska i oktober 2027 respektive oktober 2028. Ett egenutvecklat system som fakturerar andra företag har det projektet framför sig oavsett vad som händer med VERI*FACTU. Vi går igenom det kravet i vår guide till B2B-e-fakturering i Spanien.

Vem som omfattas och vem som inte gör det

AEAT:s frågor och svar om tillämpningsområdet kokar ner det till fyra negationer. Du omfattas om du inte fakturerar uteslutande för hand, inte ingår i SII (vare sig obligatoriskt eller frivilligt), inte har din skatterättsliga hemvist i Baskien eller Navarra och inte har något beslut om undantag.

Undantagen i praktiken:

• Den som rapporterar via SII. Suministro Inmediato de Información är obligatoriskt för företag med en omsättning över 6 miljoner euro, för momsgrupper och för företag i registret för månatlig momsåterbetalning (REDEME), och andra kan välja att ansluta sig. AEAT säger det rakt ut: ”El ámbito subjetivo de ambos proyectos es excluyente.” Går du över till SII slutar du skicka VERI*FACTU-poster och slutar skriva ut QR-koden.
• Baskien och Navarra. Företag med skatterättslig hemvist där lyder under de regionala (forales) skattemyndigheterna och deras egna regler, inte under RD 1007/2023.
• Helt manuell fakturering. En fakturabok på papper omfattas inte. Inte heller ett kalkylark som bara används för att skriva, skriva ut och spara fakturor; ett kalkylark som också tar fram dina momsböcker omfattas däremot.

Utländska företag omfattas när de har ett fast driftställe i Spanien.

Fakturerar du från ett kommersiellt program (A3, Sage, Holded och liknande) är leverantören producent och måste leverera en anpassad version med en egen försäkran. Uppdatera, kontrollera att försäkran finns, och sedan kan du sluta läsa här.

Den här artikeln är för alla andra: ett specialutvecklat affärssystem, ett Access-, Delphi- eller FileMaker-program som skrevs för femton år sedan, eller en faktureringsmodul i din egen webbplattform.

Ditt företag är producenten

Artikel 13.1 i förordningen lägger certifieringen på den som producerar systemet, genom en declaración responsable (en egen försäkran). AEAT:s frågor och svar om certifiering besvarar fallet med egenutvecklad programvara direkt: ”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.”

Vad det betyder i praktiken:

• Det finns ingen extern granskning. AEAT kallar det producentens ”auto-certificación”. Ingen godkänner ditt system i förväg. Du skriver under, och du står för det.
• En leverantör som bygger ett tillägg åt dig som en produkt certifierar det tillägget. Har du byggt det själv certifierar du det själv.
• Försäkran ska synas inne i systemet, i varje version, och även gå att nå utanför det, oberoende av produkten.
• Innehållet är fastställt i artikel 15 i Orden HAC/1177/2024: bland annat systemets namn, identifierare och version, dess komponenter, om det bara fungerar i VERI*FACTU-läge, producentens namn, NIF och adress samt datum och ort för underskriften.

Det besvärliga fallet är programmet vars upphovsperson slutade för flera år sedan. Någon måste ändå ta fram den anpassade versionen och skriva under för den. Bestäm vem det är, skriftligen, innan arbetet börjar.

Anpassningar av en certifierad kommersiell produkt kräver bara en separat försäkran om ändringen påverkar hur förordningens krav är implementerade. En ändring som görs utanför producentens kontroll och som kan påverka dem uppfyller inte kraven.

Insatserna bestäms av artikel 201 bis i den allmänna skattelagen: en fast sanktionsavgift på 150 000 € per räkenskapsår och per systemtyp för att producera system som inte uppfyller kraven, och 50 000 € per räkenskapsår för att inneha ett system som borde vara certifierat men inte är det, eller som har ändrats. Vilken av dem ett egenbyggt system skulle drabbas av är en fråga för din skatterådgivare. Inget av beloppen är litet.

Vad programvaran måste göra

En post för varje faktura, i samma ögonblick som den utfärdas

Artikel 9.1 kräver att systemet genererar en registro de facturación de alta ”de forma simultánea o inmediatamente anterior a la expedición de cada factura”. En makulerad faktura får en annulleringspost (registro de anulación).

Artikel 10 räknar upp vad posten innehåller: utfärdarens NIF och namn, mottagaren där det krävs, serie och nummer, utfärdande- och transaktionsdatum, fakturatyp, uppgifter om en eventuell faktura som korrigeras, en beskrivning, totalbeloppet, momsordningen, beskattningsunderlag, skattesatser och belopp, skäl för undantag eller för att transaktionen inte är skattepliktig, identiteten på systemet och dess producent samt en tidsstämpel på sekunden.

I äldre system är det här arbetet gömmer sig:

• Momsuppdelningen räknas ofta ut först vid utskrift och lagras aldrig. Den måste finnas som data när fakturan utfärdas.
• Att ”utfärda” är ofta bara att skriva ut en rapport. Det måste finnas en tydlig punkt där ett utkast blir en faktura, och det är då posten skapas.
• Det är slut med att återanvända nummer. Att radera en faktura och återanvända dess nummer, en vana i många små system, fungerar inte längre: AEAT avvisar den andra posten som ”Registro de facturación duplicado.” Testfakturor som utfärdas i produktion är riktiga fakturor och måste annulleras.
• Ingen redigerar poster. Enligt AEAT:s frågor och svar får direkta ändringar i databasen med utfärdade poster inte vara en tillåten åtgärd. Rättar personalen i dag fakturor med SQL upphör det. Rättelser görs med korrigeringsfakturor.

Hashkedjan

Varje post innehåller serie, nummer och datum för den föregående posten samt en del av dess hash (huella). Algoritmen är SHA-256, och exakt vilka fält som ingår och hur de sammanfogas står i AEAT:s tekniska dokumentation, tillsammans med postformaten, XSD-scheman, WSDL och katalogen över valideringar och fel.

Innan systemet genererar en ny post måste det kontrollera att den senaste är korrekt kedjad och att dess tidsstämpel inte ligger mer än en minut efter aktuell tid. Posterna genereras i den ordning fakturorna utfärdas.

Det får konsekvenser för arkitekturen. Varje installation behöver en enda, serialiserad punkt där posterna skapas. Två webbservrar som lägger till poster i samma kedja utan samordning kommer att bryta den. AEAT godtar blandade upplägg, till exempel kassaterminaler som får posten från ett centralt backoffice, men själva kedjan finns på ett ställe.

Varje system identifieras av den skattskyldiges NIF, ett systemid på två tecken och ett installationsnummer som aldrig får upprepas, inte ens när samma programvara installeras om på samma maskin.

QR-koden på fakturan

Varje faktura har en QR-kod enligt ISO/IEC 18004, mellan 30x30 och 40x40 mm, med felkorrigeringsnivå M. Den kodar en URL med utfärdarens NIF, serie och nummer, utfärdandedatum och totalbelopp, som kunden kan kontrollera mot AEAT. I VERI*FACTU-läge anger fakturan också ”VERI*FACTU” eller ”Factura verificable en la sede electrónica de la AEAT”.

För äldre programvara innebär det att fakturamallen måste göras om (en Access-rapport, en FileMaker-layout, en PDF-generator) och att ett QR-bibliotek måste läggas till i en teknikstack som aldrig har haft något.

Två lägen: VERI*FACTU eller inte

VERI*FACTU-läge. Systemet skickar varje post automatiskt till AEAT när den genereras. I gengäld behöver posterna en hash men ingen elektronisk underskrift, AEAT lagrar dem, och ett system som bara fungerar i det här läget behöver ingen händelselogg. Du behöver en SOAP-klient mot AEAT:s publicerade tjänster, ett kvalificerat elektroniskt certifikat och en kö för när förbindelsen går ner. AEAT:s frågor och svar för utvecklare behandlar ett avbrott som en incident: posterna väntar i kön och skickas på nytt, och faktureringen fortsätter.

Läge utan VERI*FACTU. Posterna stannar hos dig, och var och en måste signeras (XAdES Enveloped, ETSI EN 319 132) med ett kvalificerat certifikat. Systemet måste också föra en signerad händelselogg som täcker start och stopp i det här läget, kontroller av avvikelser och vad de visar, återställningar från säkerhetskopior och exporter, med en sammanfattande händelse minst var sjätte drifttimme, och det måste lämna ut posterna när AEAT begär det.

För ett specialbyggt system är enbart VERI*FACTU oftast det mindre bygget. Ingen signeringsinfrastruktur, ingen händelselogg, inga verktyg för avvikelsekontroll. Ett system som erbjuder båda lägena måste implementera allt.

En plan medan datumet är osäkert

Planera mot det lagstadgade datumet, inte det aviserade. Från mitten av oktober har den som deklarerar bolagsskatt ungefär elva veckor, vilket är snålt för det som följer. Steg 1 till 6 är samma arbete oavsett vilket datum som till slut gäller, eftersom ministeriet säger att kärnkraven förblir i allt väsentligt desamma. Det en uppskjutning skulle ändra är steg 7.

1. Vecka 1: inventering. Lista alla system som utfärdar fakturor: affärssystemet, webbutikens faktureringsmodul, prenumerationsskriptet, kassaterminalen. Bekräfta att du inte ingår i SII eller lyder under regionala regler.
2. Vecka 1 till 2: bestäm vem som skriver under och vilket läge. Utse producenten för varje system. Välj enbart VERI*FACTU om du inte har skäl att låta bli. Se till att företagets kvalificerade certifikat finns och att någon ansvarar för det, eftersom AEAT:s frågor och svar för utvecklare påpekar att systemet inte kan fungera utan det.
3. Vecka 2 till 4: gapanalys av data. Jämför det ditt system lagrar med artikel 10 och AEAT:s postformat. Saknade momsuppdelningar, koder för fakturatyp och referenser till korrigerade fakturor dyker upp här.
4. Vecka 3 till 8: bygg. Postgenerering vid utfärdande, kedjan och dess kontroller, oföränderlig lagring, annullering, QR-koden på varje mall och klienten för inskick med sin kö för nya försök. Ta bort möjligheten att ändra utfärdade poster direkt.
5. Vecka 6 till 10: testa. Börja i AEAT:s testmiljö och skicka sedan riktiga poster. AEAT betraktar tiden före din deadline som en testperiod, då du får sluta skicka och gå tillbaka till ett annat system. Läs frågor och svar för utvecklare innan du skriver flödena för annullering och korrigering: där finns de flesta specialfallen.
6. Vecka 9 till 12: skriv försäkran och utbilda. Skriv din declaración responsable, visa den i applikationen och utanför den, och dokumentera versionen. Säg till ekonomiavdelningen att nummer aldrig återanvänds och att fel rättas med korrigeringsfakturor.
7. Mitten av december: driftstart. En deadline som lyder ”antes del 1 de enero” är inget datum för driftstart. Gå i drift två veckor tidigare, så att de första problemen dyker upp medan det fortfarande finns tid. Har en författning som flyttar datumet publicerats i BOE vid det laget är det här steget du skjuter upp.

För datumet 1 juli 2027 gäller samma plan, med mer marginal. Börja i januari, inte i maj.

Två alternativ till att bygga om är värda att väga ärligt. AEAT godtar blandade arkitekturer, så ditt affärssystem kan fortsätta ta fram fakturadata medan en separat komponent, köpt eller byggd, genererar posterna, QR-koden och inskicket, förutsatt att försäkringarna täcker hur delarna hänger ihop. Och om det gamla programmet bara utfärdar en handfull fakturor i månaden kan AEAT:s kostnadsfria faktureringsprogram för småföretag, eller ett standardprogram, kosta mindre än att anpassa det.

Var du får hjälp

Vi ändrar faktureringskod som företag redan kör, även på äldre teknikstackar: postgenerering, hashkedjan, QR-koden på dina mallar och klienten för inskick till AEAT, med tester som blir kvar när vi är klara. Vår tjänst för integration av e-fakturering omfattar bygget, och underhåll av äldre system är där det börjar när ingen som är kvar vet hur det gamla programmet fungerar.

Har du datumet 1 januari 2027 och ett egenutvecklat system, skriv till office@c9group.dev. Vi är ingenjörer, inte skatterådgivare: frågor om tillämpningsområde och ansvar hör hemma hos din rådgivare, och vi bygger efter det svar de ger.