VERI*FACTU og egenutviklet faktureringsprogramvare: hva Spania krever innen 1. januar 2027

Før 1. januar 2027 må alle selskaper i Spania som leverer selskapsskattemelding (Impuesto sobre Sociedades) og fakturerer fra programvare, bruke programvare som er tilpasset Real Decreto 1007/2023. Hver faktura får en hashet post som er kjedet til den forrige, og en QR-kode kunden kan kontrollere mot skattemyndigheten. Alle andre som omfattes, i hovedsak selvstendig næringsdrivende, har frist til 1. juli 2027.

Kommer fakturaene dine fra en kommersiell pakke, er dette i stor grad leverandørens jobb. Kommer de fra programvare noen har skrevet for deg, eller som ditt eget team har skrevet, er det din. Du endrer koden, og du signerer erklæringen om at den oppfyller kravene.

Datoene, og de to utsettelsene

Dette er det tredje settet med datoer, så en viss skepsis er rimelig.

• Real Decreto 1007/2023 ga opprinnelig virksomhetene frist til 1. juli 2025.
• Real Decreto 254/2025 av 1. april 2025 flyttet fristen til 1. januar 2026 for dem som leverer selskapsskattemelding, og 1. juli 2026 for resten. Grunnen var konkret: den tekniske forskriften, Orden HAC/1177/2024, ble først publisert 28. oktober 2024.
• Real Decreto-ley 15/2025 av 2. desember 2025 flyttet begge datoene med ett år. Teksten står i BOE, og Kongressen godkjente den samme måned.

AEATs merknad om forlengelsen, oppdatert 26. mars 2026, er entydig: «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 fristen flyttes igjen? Ingenting offisielt tyder på det per oktober 2026. Den første utsettelsen hadde en teknisk årsak som ikke lenger finnes. AEATs innsendingstjenester har vært i produksjon siden 23. april 2025, og siden 29. juli 2025 har programvareleverandører bare kunnet tilby tilpassede systemer. Å regne med en tredje utsettelse er et veddemål, ikke en plan.

Hvilken dato gjelder deg? Et SL eller SA leverer Impuesto sobre Sociedades, så et selskap med eget ERP-system er nesten helt sikkert på datoen 1. januar 2027. Det er under tre måneder unna. Julidatoen gjelder selvstendig næringsdrivende og de andre skattytere som omfattes.

Hvem som omfattes, og hvem som ikke gjør det

AEATs spørsmål og svar om virkeområdet koker det ned til fire negative vilkår. Du er omfattet hvis du ikke fakturerer utelukkende for hånd, ikke er med i SII (pålagt eller frivillig), ikke har skattemessig hjemsted i Baskerland eller Navarra, og ikke har et vedtak om fritak.

Unntakene i praksis:

• Virksomheter i SII. Suministro Inmediato de Información er obligatorisk for selskaper med omsetning over 6 millioner euro, mva-grupper og virksomheter i registeret for månedlig tilbakebetaling av mva (REDEME), og andre kan melde seg inn frivillig. AEAT sier det rett ut: «El ámbito subjetivo de ambos proyectos es excluyente.» De to ordningene utelukker hverandre. Går du inn i SII, slutter du å sende VERI*FACTU-poster og å skrive ut QR-koden.
• Baskerland og Navarra. Virksomheter med skattemessig hjemsted der svarer til de forale skattemyndighetene og deres egne regler, ikke RD 1007/2023.
• Rent manuell fakturering. En fakturabok på papir er utenfor virkeområdet. Det samme er et regneark som bare brukes til å skrive, skrive ut og oppbevare fakturaer; et regneark som også lager mva-bøkene dine, er det ikke.

Utenlandske selskaper er omfattet når de har et fast driftssted i Spania.

Fakturerer du fra en kommersiell pakke (A3, Sage, Holded og lignende), er leverandøren produsenten og må levere en tilpasset versjon med sin egen erklæring. Oppdater den, kontroller at erklæringen er der, og så kan du slutte å lese.

Denne artikkelen er for resten: et skreddersydd ERP-system, et Access-, Delphi- eller FileMaker-program skrevet for femten år siden, eller en faktureringsmodul inne i din egen nettplattform.

Selskapet ditt er produsenten

Artikkel 13.1 i forskriften legger sertifiseringen på den som produserer systemet, gjennom en declaración responsable (egenerklæring). AEATs spørsmål og svar om sertifisering besvarer tilfellet med egenutviklet programvare 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.»

Hva det betyr i praksis:

• Det er ingen ekstern revisjon. AEAT kaller det en «auto-certificación» fra produsenten. Ingen godkjenner systemet ditt på forhånd. Du signerer, og du står ansvarlig.
• En leverandør som bygger en utvidelse for deg som et produkt, sertifiserer den utvidelsen. Har du bygget den selv, sertifiserer du den.
• Erklæringen må være synlig inne i systemet, i hver versjon, og også tilgjengelig utenfor det, uavhengig av produktet.
• Innholdet er fastsatt i artikkel 15 i Orden HAC/1177/2024: blant annet systemets navn, identifikator og versjon, komponentene, om det bare fungerer i VERI*FACTU-modus, produsentens navn, NIF og adresse, samt dato og sted for signering.

Det vanskelige tilfellet er programmet der forfatteren sluttet for mange år siden. Noen må fortsatt lage den tilpassede versjonen og signere for den. Avgjør hvem det er, skriftlig, før arbeidet starter.

Tilpasning av et sertifisert kommersielt produkt krever bare en egen erklæring hvis endringen berører hvordan forskriftens krav er implementert. En endring gjort utenfor produsentens kontroll som kan påvirke dem, oppfyller ikke kravene.

Hva som står på spill, er fastsatt i artikkel 201 bis i den spanske skatteforvaltningsloven (Ley General Tributaria): en fast bot på 150 000 euro per regnskapsår og per systemtype for å produsere systemer som ikke oppfyller kravene, og 50 000 euro per regnskapsår for å ha et system som burde vært sertifisert og ikke er det, eller som er endret. Hvilken av disse et egenutviklet system ville utløse, er et spørsmål for skatterådgiveren din. Ingen av beløpene er små.

Hva programvaren må gjøre

En post for hver faktura, i det øyeblikket den utstedes

Artikkel 9.1 krever at systemet lager 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 utstedelsen av hver faktura. En annullert faktura får en annulleringspost (registro de anulación).

Artikkel 10 lister opp hva posten inneholder: utstederens NIF og navn, mottakeren der det kreves, serie og nummer, utstedelses- og transaksjonsdato, fakturatype, opplysninger om en eventuell faktura den korrigerer, en beskrivelse, totalbeløpet, mva-ordningen, avgiftsgrunnlag, satser og beløp, grunner til fritak eller til at transaksjonen faller utenfor avgiftsområdet, identiteten til systemet og produsenten, og et tidsstempel med sekundpresisjon.

I eldre systemer er det her arbeidet skjuler seg:

• Mva-oppstillinger beregnes ofte i utskriftsøyeblikket og lagres aldri. De må finnes som data i det øyeblikket fakturaen utstedes.
• «Utstedelse» er ofte bare utskrift av en rapport. Det må finnes et uttrykkelig punkt der et utkast blir en faktura, og posten lages da.
• Gjenbruk av numre er slutt. Å slette en faktura og gjenbruke nummeret, en vane i mange små systemer, feiler nå: AEAT avviser den andre posten som «Registro de facturación duplicado.» Testfakturaer utstedt i produksjon er ekte fakturaer og må annulleres.
• Ingen redigerer poster. AEATs spørsmål og svar sier at direkte endringer i databasen over utstedte poster ikke skal være en tillatt operasjon. Retter de ansatte fakturaer med SQL i dag, er det slutt på det. Rettelser går gjennom korrigerende fakturaer.

Hashkjeden

Hver post inneholder serie, nummer og dato for den forrige posten og en del av dens hash (huella). Algoritmen er SHA-256, og de nøyaktige feltene og sammenkjedingen står i AEATs tekniske dokumentasjon, sammen med postformatene, XSD-skjemaer, WSDL og katalogen over valideringer og feil.

Før en ny post lages, må systemet kontrollere at den forrige er riktig kjedet, og at tidsstempelet ikke er mer enn ett minutt senere enn nåværende tid. Postene lages i den rekkefølgen fakturaene utstedes.

Det har en arkitektonisk konsekvens. Hver installasjon trenger ett enkelt, serialisert punkt der poster opprettes. To webservere som legger til i den samme kjeden uten koordinering, vil ødelegge den. AEAT godtar blandede oppsett, som kasseterminaler som får posten fra et sentralt bakkontor, men selve kjeden bor ett sted.

Hvert system identifiseres med skattyterens NIF, en systemidentifikator på to tegn og et installasjonsnummer som aldri kan gjentas, heller ikke når samme programvare installeres på nytt på samme maskin.

QR-koden på fakturaen

Hver faktura har en QR-kode etter ISO/IEC 18004, mellom 30 x 30 og 40 x 40 mm, med feilrettingsnivå M. Den koder en URL med utstederens NIF, serie og nummer, utstedelsesdato og totalbeløp, som kunden kan kontrollere mot AEAT. I VERI*FACTU-modus står det også «VERI*FACTU» eller «Factura verificable en la sede electrónica de la AEAT» på fakturaen.

For eldre programvare betyr det å bygge om fakturamalen (en Access-rapport, et FileMaker-oppsett, en PDF-generator) og legge til et QR-bibliotek i en plattform som aldri har hatt et.

To moduser: VERI*FACTU eller ikke

VERI*FACTU-modus. Systemet sender hver post automatisk til AEAT idet den lages. Til gjengjeld trenger postene en hash, men ingen elektronisk signatur, AEAT oppbevarer dem, og et system som bare fungerer i denne modusen, trenger ingen hendelseslogg. Du trenger en SOAP-klient mot AEATs publiserte tjenester, et kvalifisert elektronisk sertifikat og en kø for når forbindelsen svikter. AEATs spørsmål og svar for utviklere behandler et avbrudd som en hendelse: postene venter i køen og sendes på nytt, og faktureringen fortsetter.

Modus uten VERI*FACTU. Postene blir hos deg, og hver av dem må signeres (XAdES Enveloped, ETSI EN 319 132) med et kvalifisert sertifikat. Systemet må også føre en signert hendelseslogg som dekker oppstart og stopp i denne modusen, avvikskontroller og hva de finner, gjenoppretting fra sikkerhetskopi og eksport, med en oppsummeringshendelse minst hver sjette driftstime, og det må utlevere postene når AEAT ber om det.

For et skreddersydd system er ren VERI*FACTU som regel den minste jobben. Ingen signeringsinfrastruktur, ingen hendelseslogg, ingen verktøy for avvikskontroll. Et system som tilbyr begge modusene, må implementere alt sammen.

En plan som rekker før 1. januar 2027

Fra begynnelsen av oktober har et selskap som leverer selskapsskattemelding, omtrent tretten uker. Dette er rekkefølgen som fungerer.

1. Uke 1: kartlegging. List opp hvert system som utsteder fakturaer: ERP-systemet, nettbutikkens faktureringsmodul, abonnementsskriptet, kasseterminalen. Bekreft at dere ikke er i SII eller under forale regler.
2. Uke 1 til 2: avgjør hvem som signerer, og hvilken modus. Utpek produsenten for hvert system. Velg ren VERI*FACTU med mindre dere har en grunn til noe annet. Sørg for at selskapets kvalifiserte sertifikat finnes og at noen har ansvaret for det, for AEATs spørsmål og svar for utviklere påpeker at systemet ikke kan fungere uten.
3. Uke 2 til 4: gapanalyse av dataene. Sammenlign det systemet ditt lagrer, med artikkel 10 og AEATs postformat. Manglende mva-oppstillinger, koder for fakturatype og referanser til korrigerte fakturaer viser seg her.
4. Uke 3 til 8: utvikling. Generering av poster ved utstedelse, kjeden og kontrollene, uforanderlig lagring, annullering, QR-koden på hver mal og innsendingsklienten med kø for nye forsøk. Fjern direkte redigering av utstedte poster.
5. Uke 6 til 10: testing. Start i AEATs testmiljø, og send deretter ekte poster. AEAT behandler tiden før fristen din som en testperiode, der du kan slutte å sende og falle tilbake på et annet system. Les spørsmål og svar for utviklere før du skriver flytene for annullering og korrigering: de dekker de fleste spesialtilfellene.
6. Uke 9 til 12: erklær og lær opp. Skriv declaración responsable, vis den i applikasjonen og utenfor den, og registrer versjonen. Fortell økonomiavdelingen at numre aldri gjenbrukes, og at feil rettes med korrigerende fakturaer.
7. Midten av desember: gå i drift. En frist som lyder «antes del 1 de enero», er ikke en oppstartsdato. Gå i drift to uker før, slik at de første problemene dukker opp mens det fortsatt er tid.

For datoen 1. juli 2027 gjelder samme plan, med bedre tid. Start i januar, ikke i mai.

To alternativer til å bygge om er verdt å vurdere ærlig. AEAT godtar blandede arkitekturer, så ERP-systemet ditt kan fortsette å klargjøre fakturadata mens en separat komponent, kjøpt eller bygget, lager postene, QR-koden og innsendingen, forutsatt at erklæringene dekker hvordan delene henger sammen. Og utsteder det gamle programmet en håndfull fakturaer i måneden, kan AEATs gratis faktureringsapplikasjon for små virksomheter, eller en standardpakke, koste mindre enn å tilpasse det.

Hvor du får hjelp

Vi endrer faktureringskode som selskaper allerede kjører, også på eldre plattformer: generering av poster, hashkjeden, QR-koden på malene dine og innsendingsklienten mot AEAT, med tester som blir igjen etter oss. Vår tjeneste for e-fakturaintegrasjon dekker utviklingen, og vedlikehold av eldre systemer er der det starter når ingen som er igjen, vet hvordan det gamle programmet virker.

Har du fristen 1. januar 2027 og et egenutviklet system, skriv til office@c9group.dev. Vi er ingeniører, ikke skatterådgivere: spørsmål om virkeområde og ansvar hører hjemme hos deres rådgiver, og vi bygger etter svaret de gir.