Cosa deve rispettare il tuo software per VeriFactu: i requisiti, uno per uno

Da dove arrivano i requisiti

Da due norme da leggere insieme. Il Real Decreto 1007/2023 approva il Regolamento e dice che cosa bisogna garantire; la Orden HAC/1177/2024 scende nel dettaglio e dice come: formati, algoritmi, millimetri. Tutto ciò che segue deriva da lì.

1. I sei aggettivi dell’articolo 8

L’articolo 8 è la colonna vertebrale. Richiede che il sistema garantisca l’integrità, conservazione, accessibilità, leggibilità, tracciabilità e inalterabilità dei registri di fatturazione. Sembra una dichiarazione d’intenti, ma il comma 2 la concretizza ed è lì che morde:

• 8.2.a) — una volta generati e registrati, i dati non possono essere alterati senza che il sistema lo rilevi. Si considera alterazione sia nascondere o eliminare un registro, sia modificarne i dati. Qualsiasi correzione si fa con un registro successivo aggiuntivo, conservando l’originale.
• 8.2.b) — i registri devono essere concatenati, in modo che se ne possa verificare la traccia seguendo la sequenza di creazione dal primo all’ultimo.

Come si verifica: chiedi una dimostrazione di che cosa succede quando si cerca di correggere una fattura già emessa. Se il programma permette di modificarla e salvare, non è conforme. Deve condurti a una rettifica o a un annullamento.

2. Il registro di alta: quando nasce e che cosa contiene

L’articolo 9 fissa il momento: il registro di fatturazione di alta (cioè di emissione) viene generato contestualmente o immediatamente prima dell’emissione di ogni fattura. Non è un processo notturno né un pulsante che qualcuno preme a fine mese.

L’articolo 10 ne elenca il contenuto: identificazione fiscale dell’emittente e del destinatario, numero e serie, date, tipo di fattura, ripartizione di imponibili e imposte, l’impronta del registro precedente, l’identificazione del sistema informatico che lo genera e la marca temporale, tra gli altri. Sono diciassette elementi.

Come si verifica: chiedi se il registro viene creato all’interno della stessa transazione della fattura. Se la fattura può risultare emessa e il registro fallire separatamente, hai una falla: due verità diverse sullo stesso documento.

3. L’impronta: SHA-256 e catena

L’articolo 12 del Regolamento richiede di aggiungere un’impronta o hash ai registri di alta e di annullamento. La Orden HAC/1177/2024, nel suo articolo 13, specifica l’algoritmo —SHA-256— e quali campi esatti entrano nel calcolo a seconda del tipo di registro.

Ogni registro incorpora parte dell’impronta del precedente. Questo costruisce una catena: se qualcuno manipolasse un registro intermedio, tutte le impronte successive smetterebbero di tornare. È il meccanismo che rende verificabile l’inalterabilità dell’articolo 8.

Come si verifica: chiedi se il sistema dispone di una funzione per verificare l’integrità dell’intera catena e che cosa fa se rileva un’interruzione. Un programma che calcola le impronte ma non le controlla mai ti darà la cattiva notizia il giorno dell’ispezione, non prima.

4. Il registro di annullamento

L’articolo 11 disciplina il registro di fatturazione di annullamento, che si genera quando una fattura è stata emessa per errore. È importante capire che cosa non è: non cancella nulla. Aggiunge un registro che dà conto dell’annullamento, e l’originale resta.

Come si verifica: guarda se il programma distingue tra annullare (la fattura non doveva esistere) e rettificare (l’importo o i dati erano diversi). Non sono la stessa cosa e non si risolvono allo stesso modo.

5. Il registro degli eventi

Meno conosciuto e molto citato a metà. L’articolo 8.3 richiede che il sistema disponga di un registro degli eventi che raccolga automaticamente determinate interazioni e operazioni, senza che l’utente possa intervenire. L’idea è lasciare traccia di ciò che accade attorno ai registri di fatturazione —avvii, modifiche di configurazione, incidenti—, non solo delle fatture.

Come si verifica: chiedi di vedere quel registro. Deve esistere come tale all’interno del sistema e non essere il log tecnico del server che il fornitore consulta quando gli va.

6. Le due modalità: inviare o firmare

L’articolo 15 apre la porta all’invio volontario dei registri e l’articolo 16 definisce che cos’è un sistema VERI*FACTU: quello che li invia «in modo continuato, sicuro, corretto, integro, automatico, consecutivo, istantaneo e fededegno». La scelta ha conseguenze:

Per la maggior parte delle PMI, VERI*FACTU risulta meno oneroso in termini di complessità: si scambia l’onere di firmare e custodire con quello di essere connessi.

7. Il QR e la dicitura sulla fattura

L’Orden arriva al millimetro. Il suo articolo 21 richiede un codice QR di 30-40 millimetri di lato, conforme allo standard ISO/IEC 18004, che contiene il NIF dell’emittente, il numero di fattura, la data e l’importo. E la fattura deve riportare la dicitura corrispondente alla modalità.

Come si verifica: emetti una fattura di prova e scansiona il QR con il cellulare. Deve condurti al servizio di verifica dell’Agencia Tributaria. E attenzione a un dettaglio che sfugge: se il sistema sta lavorando nell’ambiente di test, il QR deve puntare all’ambiente di test, non alla sede reale, dove quella fattura non esiste.

8. La dichiarazione responsabile

L’articolo 13 del Regolamento obbliga il produttore del software a rilasciare una dichiarazione responsabile che certifichi che il sistema rispetta quanto disposto dall’articolo 29.2.j) della Ley General Tributaria (legge generale tributaria) e dal Regolamento stesso. Deve risultare per iscritto e in modo visibile nel sistema informatico stesso, in ciascuna delle sue versioni, e va consegnata a clienti e distributori.

Due conseguenze pratiche che quasi nessuno menziona:

• È per versione. Un fornitore con rilascio continuo ha bisogno di una politica di versionamento e di conservare la dichiarazione di tutte le versioni prodotte.
• Sta dentro il programma. Non è un PDF nel cassetto commerciale: deve poter essere consultata dal sistema stesso.

Ciò che la norma non dice e si nota in produzione

Fin qui, la lettera. Questi quattro punti non vengono dal BOE (la Gazzetta ufficiale spagnola), vengono dall’avere il sistema in funzione:

1. Nuovo tentativo degli invii. La sede dell’Agencia Tributaria ha interruzioni e finestre di manutenzione. Se un guasto di rete blocca la tua fatturazione, il problema è di progettazione, non dell’AEAT. Il registro è già generato e concatenato; l’invio deve essere ritentato da solo, con lo stato di ciascuno visibile.
2. La modalità si congela nella fattura. Ciò che conta è come è stato emesso il documento, non come è configurato il sistema il giorno in cui qualcuno lo ristampa. Se la dicitura del PDF viene calcolata al volo, una futura ristampa può contraddire la fattura originale.
3. Un vero ambiente di test. Prima di fatturare in reale bisogna poter fare delle prove contro l’ambiente di test dell’AEAT, con il suo URL di verifica.
4. Più società, più catene. Se emetti da più di un’azienda, ciascuna ha bisogno della propria numerazione, del proprio certificato e della propria catena di impronte, senza mescolarsi. Ne parliamo in VeriFactu in un’impresa di trasporto.

Dieci domande per il tuo fornitore

1. Mi mostri la dichiarazione responsabile della versione che ho in abbonamento?
2. In quale modalità lavora il sistema, VERI*FACTU o non verificabile?
3. Il registro di alta viene generato nella stessa transazione della fattura?
4. Posso verificare la catena delle impronte dal programma stesso?
5. Che cosa succede esattamente se provo a modificare una fattura già emessa?
6. Distingue l’annullamento dalla rettifica?
7. Dove vedo il registro degli eventi?
8. Che cosa succede se l’AEAT non risponde? Si ritenta da solo? Lo vedo?
9. Se fatturo da due società, ciascuna ha la sua serie e il suo certificato?
10. Se l’anno prossimo entro nel SII (Suministro Inmediato de Información, il sistema spagnolo di invio immediato dei dati IVA), che cosa devo cambiare?