VERI*FACTU e software di fatturazione su misura: cosa chiede la Spagna entro il 1° gennaio 2027

Entro il 1° gennaio 2027 ogni società in Spagna che presenta la dichiarazione dell'imposta sulle società (Impuesto sobre Sociedades) e fattura tramite software deve usare un software adeguato al Real Decreto 1007/2023. Ogni fattura riceve un record con hash concatenato al precedente e un codice QR che il cliente può verificare presso l'agenzia delle entrate spagnola. Tutti gli altri soggetti obbligati, per lo più lavoratori autonomi, hanno tempo fino al 1° luglio 2027.

Se le vostre fatture escono da un pacchetto commerciale, il lavoro spetta in gran parte al vostro fornitore. Se escono da un software che qualcuno ha scritto per voi, o che ha scritto il vostro team, spetta a voi. Siete voi a modificare il codice, e siete voi a firmare la dichiarazione che ne attesta la conformità.

Le date e i due rinvii

È la terza serie di date, quindi un po' di scetticismo è legittimo.

• Il Real Decreto 1007/2023 dava inizialmente alle imprese tempo fino al 1° luglio 2025.
• Il Real Decreto 254/2025, del 1° aprile 2025, ha spostato la scadenza al 1° gennaio 2026 per chi presenta l'imposta sulle società e al 1° luglio 2026 per gli altri. La ragione era concreta: l'ordinanza tecnica, la Orden HAC/1177/2024, era stata pubblicata solo il 28 ottobre 2024.
• Il Real Decreto-ley 15/2025, del 2 dicembre 2025, ha spostato entrambe le date di un anno. Il testo è nel BOE, e il Congresso lo ha convalidato nello stesso mese.

La nota dell'AEAT sulla proroga, aggiornata il 26 marzo 2026, non lascia dubbi: «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.» In sostanza: le società soggette all'imposta sulle società devono aver adeguato i propri sistemi di fatturazione (SIF) prima del 1° gennaio 2027, tutti gli altri prima del 1° luglio 2027.

Potrebbe slittare ancora? A ottobre 2026 nulla di ufficiale lo indica. Il primo rinvio aveva una causa tecnica che non esiste più. I servizi di invio dell'AEAT sono in produzione dal 23 aprile 2025, e dal 29 luglio 2025 i produttori di software possono offrire solo sistemi adeguati. Contare su un terzo rinvio è una scommessa, non un piano.

Qual è la vostra data? Una SL o una SA presenta l'Impuesto sobre Sociedades, quindi una società con un gestionale proprio è quasi certamente sulla data del 1° gennaio 2027. Mancano meno di tre mesi. La data di luglio riguarda i lavoratori autonomi e gli altri contribuenti obbligati.

Chi è dentro e chi è fuori

Le FAQ dell'AEAT sull'ambito di applicazione lo riducono a quattro condizioni negative. Rientrate se non fatturate esclusivamente a mano, non siete nel SII (per obbligo o per scelta), non avete il domicilio fiscale nei Paesi Baschi o in Navarra e non avete un provvedimento di esonero.

In pratica, le esclusioni sono:

• Chi è nel SII. Il Suministro Inmediato de Información è obbligatorio per le società con un fatturato superiore a 6 milioni di euro, per i gruppi IVA e per le imprese iscritte al registro dei rimborsi IVA mensili (REDEME), e gli altri possono aderire volontariamente. L'AEAT lo dice senza giri di parole: «El ámbito subjetivo de ambos proyectos es excluyente», cioè i due regimi si escludono a vicenda. Se entrate nel SII, smettete di inviare i record VERI*FACTU e di stampare il codice QR.
• Paesi Baschi e Navarra. Le imprese con domicilio fiscale in quei territori rispondono alle amministrazioni fiscali forali e alle loro regole, non al RD 1007/2023.
• Fatturazione puramente manuale. Un bollettario cartaceo è fuori. Lo è anche un foglio di calcolo usato solo per scrivere, stampare e conservare le fatture; uno che produce anche i vostri registri IVA invece no.

Le società estere rientrano quando hanno una stabile organizzazione in Spagna.

Se fatturate con un pacchetto commerciale (A3, Sage, Holded e simili), il produttore è il fornitore, che deve distribuire una versione adeguata con la propria dichiarazione. Aggiornatela, verificate che la dichiarazione ci sia, e potete fermarvi qui.

Questo articolo è per tutti gli altri: un gestionale su misura, un programma in Access, Delphi o FileMaker scritto quindici anni fa, o un modulo di fatturazione dentro la vostra piattaforma web.

Il produttore è la vostra azienda

L'articolo 13.1 del regolamento attribuisce la certificazione a chi produce il sistema, tramite una declaración responsable (dichiarazione responsabile). Le FAQ dell'AEAT sulla certificazione rispondono direttamente al caso dello sviluppo interno: «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.» Ogni sistema in uso deve avere la sua certificazione, e se il software l'ha sviluppato l'azienda stessa, tocca all'azienda certificarlo.

Cosa significa in pratica:

• Non c'è un audit esterno. L'AEAT la chiama «auto-certificación» del produttore. Nessuno approva il vostro sistema in anticipo. Firmate voi, e ne rispondete voi.
• Un fornitore esterno che sviluppa per voi un'estensione come prodotto certifica quell'estensione. Se l'avete sviluppata voi, la certificate voi.
• La dichiarazione deve essere visibile dentro il sistema, in ogni versione, e raggiungibile anche fuori, indipendentemente dal prodotto.
• Il suo contenuto è fissato dall'articolo 15 della Orden HAC/1177/2024: tra l'altro, nome, identificativo e versione del sistema, i suoi componenti, se funziona solo in modalità VERI*FACTU, nome, NIF e indirizzo del produttore, e data e luogo della firma.

Il caso scomodo è il programma il cui autore se n'è andato anni fa. Qualcuno deve comunque produrre la versione adeguata e firmarla. Decidete chi, per iscritto, prima che il lavoro cominci.

Personalizzare un prodotto commerciale certificato richiede una dichiarazione separata solo se la modifica tocca il modo in cui sono implementati i requisiti del regolamento. Una modifica fatta fuori dal controllo del produttore che può alterarli non è conforme.

La posta in gioco la fissa l'articolo 201 bis della Ley General Tributaria: una sanzione fissa di 150.000 euro per esercizio e per tipo di sistema per chi produce sistemi che non rispettano i requisiti, e di 50.000 euro per esercizio per chi detiene un sistema che dovrebbe essere certificato e non lo è, o che è stato alterato. Quale delle due colpirebbe un sistema sviluppato in casa è una domanda per il vostro consulente fiscale. Nessuna delle due cifre è piccola.

Cosa deve fare il software

Un record per ogni fattura, al momento dell'emissione

L'articolo 9.1 impone al sistema di generare un registro de facturación de alta «de forma simultánea o inmediatamente anterior a la expedición de cada factura», cioè contestualmente all'emissione di ogni fattura o subito prima. Una fattura annullata riceve un record di annullamento (registro de anulación).

L'articolo 10 elenca cosa contiene il record: NIF e nome dell'emittente, il destinatario dove richiesto, serie e numero, date di emissione e di operazione, tipo di fattura, i dati dell'eventuale fattura rettificata, una descrizione, il totale, il regime IVA, imponibile, aliquote e importi, i motivi di esenzione o di non assoggettamento, l'identità del sistema e del suo produttore, e una marca temporale al secondo.

Nei sistemi datati è qui che si nasconde il lavoro:

• I riepiloghi IVA spesso vengono calcolati al momento della stampa e mai salvati. Devono esistere come dati al momento dell'emissione.
• Spesso «emettere» significa solo stampare un report. Serve un punto esplicito in cui una bozza diventa fattura, ed è lì che nasce il record.
• Il riutilizzo dei numeri è finito. Cancellare una fattura e riusarne il numero, un'abitudine in tanti piccoli sistemi, ora non funziona più: l'AEAT rifiuta il secondo record come «Registro de facturación duplicado». Le fatture di prova emesse in produzione sono fatture vere e vanno annullate.
• Nessuno modifica i record. Le FAQ dell'AEAT dicono che le modifiche dirette al database dei record emessi non devono essere un'operazione consentita. Se oggi il personale corregge le fatture con SQL, si smette. Le correzioni passano dalle fatture rettificative.

La catena di hash

Ogni record riporta serie, numero e data del record precedente e parte del suo hash (huella). L'algoritmo è SHA-256, e i campi esatti e il modo di concatenarli sono nella documentazione tecnica dell'AEAT, insieme ai tracciati dei record, agli schemi XSD, al WSDL e al catalogo delle validazioni e degli errori.

Prima di generare un nuovo record, il sistema deve verificare che l'ultimo sia concatenato correttamente e che la sua marca temporale non sia più di un minuto avanti rispetto all'ora attuale. I record si generano nell'ordine in cui si emettono le fatture.

Questo ha una conseguenza architetturale. Ogni installazione ha bisogno di un unico punto, serializzato, in cui nascono i record. Due server web che aggiungono record alla stessa catena senza coordinarsi la spezzano. L'AEAT accetta configurazioni miste, come terminali di cassa che ricevono il record da un back office centrale, ma la catena in sé vive in un solo posto.

Ogni sistema è identificato dal NIF del contribuente, da un ID di sistema di due caratteri e da un numero di installazione che non può mai ripetersi, nemmeno quando lo stesso software viene reinstallato sulla stessa macchina.

Il codice QR sulla fattura

Ogni fattura riporta un codice QR conforme a ISO/IEC 18004, di dimensioni comprese tra 30x30 e 40x40 mm, con livello di correzione degli errori M. Codifica un URL che contiene il NIF dell'emittente, serie e numero, data di emissione e totale, che il cliente può verificare presso l'AEAT. In modalità VERI*FACTU la fattura riporta anche la dicitura «VERI*FACTU» oppure «Factura verificable en la sede electrónica de la AEAT».

Per il software datato significa rifare il modello di fattura (un report di Access, un layout di FileMaker, un generatore di PDF) e aggiungere una libreria QR a uno stack che non ne ha mai avuta una.

Due modalità: VERI*FACTU oppure no

Modalità VERI*FACTU. Il sistema invia ogni record all'AEAT in automatico, nel momento in cui lo genera. In cambio i record richiedono un hash ma nessuna firma elettronica, li conserva l'AEAT, e un sistema che funziona solo in questa modalità non ha bisogno di un registro degli eventi. Vi servono un client SOAP verso i servizi pubblicati dall'AEAT, un certificato elettronico qualificato e una coda per quando la connessione cade. Le FAQ per sviluppatori dell'AEAT trattano un'interruzione come un incidente: i record restano in coda e vengono reinviati, e la fatturazione continua.

Modalità non VERI*FACTU. I record restano presso di voi, e ognuno va firmato (XAdES Enveloped, ETSI EN 319 132) con un certificato qualificato. Il sistema deve anche tenere un registro degli eventi firmato che copra avvio e arresto in questa modalità, i controlli di anomalia e i loro esiti, i ripristini da backup e le esportazioni, con un evento di riepilogo almeno ogni sei ore di funzionamento, e deve consegnare i record quando l'AEAT li chiede.

Per un sistema su misura, la sola modalità VERI*FACTU è di solito lo sviluppo più piccolo. Niente infrastruttura di firma, niente registro degli eventi, niente strumenti per le anomalie. Un sistema che offre entrambe le modalità deve implementare tutto.

Un piano che sta prima del 1° gennaio 2027

Da inizio ottobre, una società soggetta all'imposta sulle società ha circa tredici settimane. Questo è l'ordine che funziona.

1. Settimana 1: inventario. Elencate ogni sistema che emette fatture: il gestionale, il modulo di fatturazione del negozio online, lo script degli abbonamenti, il terminale del banco. Verificate di non essere nel SII né sotto regole forali.
2. Settimane 1 e 2: decidere chi firma e quale modalità. Nominate il produttore di ciascun sistema. Scegliete la sola modalità VERI*FACTU, a meno che non abbiate un motivo per fare diversamente. Assicuratevi che il certificato qualificato della società esista e che qualcuno ne sia responsabile, perché le FAQ per sviluppatori dell'AEAT ricordano che senza certificato il sistema non può funzionare.
3. Dalla settimana 2 alla 4: analisi dei dati mancanti. Confrontate ciò che il vostro sistema salva con l'articolo 10 e con il tracciato dei record dell'AEAT. Qui emergono i riepiloghi IVA mancanti, i codici del tipo di fattura e i riferimenti alle rettifiche.
4. Dalla settimana 3 alla 8: sviluppo. Generazione del record all'emissione, la catena e i suoi controlli, l'archiviazione immutabile, l'annullamento, il QR su ogni modello e il client di invio con la sua coda di reinvio. Eliminate le modifiche dirette ai record emessi.
5. Dalla settimana 6 alla 10: test. Partite dall'ambiente di prova dell'AEAT, poi inviate record reali. L'AEAT considera il periodo prima della vostra scadenza un periodo di prova, durante il quale potete interrompere gli invii e tornare a un altro sistema. Leggete le FAQ per sviluppatori prima di scrivere i flussi di annullamento e di rettifica: coprono quasi tutti i casi limite.
6. Dalla settimana 9 alla 12: dichiarazione e formazione. Redigete la declaración responsable, mostratela nell'applicazione e fuori, e registrate la versione. Spiegate all'amministrazione che i numeri non si riusano mai e che gli errori si correggono con fatture rettificative.
7. Metà dicembre: avvio. Una scadenza che dice «antes del 1 de enero», prima del 1° gennaio, non è una data di avvio. Partite con due settimane di anticipo, così i primi problemi emergono quando c'è ancora tempo.

Per la data del 1° luglio 2027 vale lo stesso piano, con più margine. Iniziate a gennaio, non a maggio.

Due alternative alla ricostruzione meritano una valutazione onesta. L'AEAT accetta architetture miste, quindi il vostro gestionale può continuare a preparare i dati di fattura mentre un componente separato, acquistato o sviluppato, genera i record, il QR e l'invio, purché le dichiarazioni coprano il modo in cui le parti si incastrano. E se il vecchio programma emette poche fatture al mese, l'applicazione di fatturazione gratuita dell'AEAT per le piccole imprese, o un pacchetto standard, può costare meno che adeguarlo.

Dove trovare aiuto

Modifichiamo il codice di fatturazione che le aziende hanno già in uso, compresi gli stack più datati: generazione dei record, catena di hash, QR sui vostri modelli e client di invio verso l'AEAT, lasciandovi i test. Il nostro servizio di integrazione della fatturazione elettronica copre lo sviluppo, e la manutenzione dei sistemi legacy è il punto di partenza quando non è rimasto nessuno che sappia come funziona il vecchio programma.

Se avete la scadenza del 1° gennaio 2027 e un sistema su misura, scrivete a office@c9group.dev. Siamo ingegneri, non consulenti fiscali: le questioni di ambito e di responsabilità spettano ai vostri, e noi sviluppiamo sulla base della loro risposta.