Perché il tuo ERP genera fatture, non prove
I software ERP e di contabilità sono straordinariamente bravi nel compito per cui sono stati progettati: elaborare transazioni su larga scala, applicare flussi di approvazione e produrre output strutturato che altri sistemi possono utilizzare. Ogni giorno milioni di fatture vengono generate così senza incidenti.
Ma c’è un compito distinto che il software ERP non è mai stato progettato per svolgere, e questa distinzione conta quando un’autorità fiscale, un tribunale o un organismo di vigilanza pone una domanda più difficile di “mostrami la fattura”.
La domanda a cui la maggior parte dei software non sa rispondere
Quando una fattura ordinaria viene contestata, di solito basta produrre il PDF. L’acquirente lo riconosce, il venditore lo conferma e la questione è risolta. È questo il flusso per cui il software ERP è ottimizzato.
Una domanda più difficile suona così: “Dimostra che questa fattura esisteva esattamente in questa forma in questa data, che da allora non è stata modificata, e che la persona che dichiara di averla inviata l’ha effettivamente inviata tramite il tuo sistema.”
Questa non è una domanda sul documento. È una domanda sulle prove. E le prove hanno requisiti diversi dai documenti.
Un documento è la registrazione di una transazione. Una prova è una registrazione verificabile in grado di reggere a un esame indipendente, compreso quello di chi sta attivamente cercando di contestarla.
Cosa offre il software ERP
Per essere precisi sulla lacuna, conviene essere chiari su ciò che il software ERP fa bene.
La maggior parte dei sistemi ERP moderni offre:
Dati di fattura strutturati. Le fatture sono memorizzate in un database con relazioni chiare tra acquirenti, venditori, righe, totali e date. Questo le rende interrogabili, verificabili tramite l’interfaccia dello stesso ERP ed esportabili in formati standardizzati come UBL o CII XML.
Log di approvazione e di audit. La maggior parte dei sistemi ERP registra chi ha approvato cosa e quando. Questi log sono utili per le verifiche del controllo interno e possono dimostrare che è stato seguito il processo corretto.
Conformità del formato. Per l’output Factur-X, ZUGFeRD, XRechnung e Peppol, il software ERP moderno genera XML che supera la validazione rispetto allo schema pertinente. Questo copre il requisito di formato previsto dagli obblighi UE di fatturazione elettronica.
Esportazione e portabilità. Di solito le fatture si possono esportare in blocco, come XML, PDF o entrambi. Questo copre il caso d’uso della portabilità dei dati.
Niente di tutto questo è banale. La conformità del formato è un vero problema di ingegneria, e i fornitori di ERP hanno investito molto per risolverlo. Il punto non è che il software ERP sia carente. Il punto è che la conformità del formato è necessaria ma non sufficiente per una prova legale.
Cosa non offre il software ERP
La lacuna emerge quando chiedi una verifica indipendente di tre cose che i procedimenti legali richiedono spesso.
Prova di esistenza in un momento specifico. Un timestamp memorizzato all’interno del tuo sistema è affidabile solo quanto il tuo sistema. Se controlli il sistema, una controparte può sostenere che controllavi anche il timestamp. Un timestamp RFC 3161 di una Time Stamping Authority indipendente è firmato crittograficamente da una terza parte e non può essere falsificato retroattivamente senza invalidare la firma. La maggior parte dei sistemi ERP non emette né conserva timestamp RFC 3161.
Prova di integrità da quel momento. Un file PDF o XML memorizzato in un database può essere modificato. Un record di database può essere aggiornato. Senza un hash commitment indipendente (un’impronta crittografica calcolata al momento della creazione e conservata in un luogo fuori dal tuo controllo), non puoi dimostrare che il documento non è stato alterato da allora. La maggior parte dei sistemi ERP non produce né conserva hash commitment crittografici legati ai propri record.
Una catena di custodia indipendente. Sapere che un documento oggi esiste in un determinato stato è diverso dal sapere come ci è arrivato. Una catena di custodia registra ogni azione compiuta su un documento (chi vi ha avuto accesso, cosa è stato fatto e in quale sequenza) in un log resistente alle manomissioni. È la prassi nei procedimenti legali e regolamentari, ma di solito non è così che sono implementati i log di audit degli ERP.
Quando conta nella pratica
La distanza tra documento e prova non è accademica. Ecco i contesti in cui emerge.
Indagini delle autorità fiscali. In diverse giurisdizioni UE, le autorità fiscali hanno il potere di esigere che le imprese dimostrino l’integrità dei propri registri di fatturazione elettronica. Un’impresa che sa produrre le fatture ma non sa dimostrare che non sono state alterate dopo l’emissione è in una posizione più debole di una che sa produrre, insieme alla fattura, una prova crittografica di integrità.
Controversie commerciali. Quando un acquirente contesta una fattura (sostenendo che è stata modificata a posteriori, o che gli importi non corrispondono a quanto concordato), il venditore deve dimostrare che il documento è autentico e invariato. Un timestamp RFC 3161 e una catena di hash forniscono questa dimostrazione. Un PDF di un sistema ERP senza verifica indipendente no.
Audit regolamentari nei servizi finanziari. Le imprese soggette a MiFID II, Solvency II o quadri equivalenti sono tenute a conservare i registri in modo da dimostrarne integrità e autenticità. I requisiti specifici variano, ma l’aspettativa generale è che i registri non possano essere alterati senza che ciò venga rilevato. È un’asticella più alta del tipico storage di un ERP.
Controversie contrattuali con lunghi periodi di conservazione. I requisiti di conservazione delle fatture nell’UE vanno da 7 anni (lo standard comune per le fatture IVA) a 20 anni per alcuni documenti del settore pubblico secondo il diritto olandese. In un arco di 7 anni possono cambiare molte cose: il sistema ERP può essere sostituito, il database migrato, i file PDF riesportati. Senza un timestamp e una catena di hash ancorati al momento della creazione, dimostrare che una fattura di 7 anni fa non è stata modificata diventa difficile.
L’equivoco della conformità del formato
Un presupposto comune è che, se una fattura è conforme a Factur-X o a Peppol, sia ammissibile in giudizio. La conformità del formato significa che la fattura supera la validazione rispetto allo schema e contiene i campi richiesti. Non dice nulla su quando il documento è stato creato, se è stato modificato o se il registro può essere verificato in modo indipendente.
Factur-X è un formato di file. RFC 3161 è un protocollo di prova. Operano a livelli diversi dello stack di conformità, e l’uno non sostituisce l’altro.
Per usare un’analogia fisica: un documento autenticato da un notaio e un documento stampato sono entrambi documenti. L’autenticazione notarile aggiunge un livello di verifica indipendente: una terza parte fidata che attesta quando e da chi il documento è stato firmato. La conformità del formato è più vicina alla stampa che all’autenticazione notarile.
Cosa richiede davvero il livello di prova
Produrre prove verificabili per un documento digitale richiede almeno tre cose.
Un timestamp affidabile. Un timestamp RFC 3161 di una Time Stamping Authority fornisce una prova crittografica di esistenza in un preciso momento. La TSA è una parte indipendente la cui firma può essere verificata da chiunque con strumenti standard. Il timestamp non può essere falsificato a posteriori senza invalidare la catena di firme.
Un hash commitment. Prima che il documento riceva il timestamp, il suo contenuto viene sottoposto a hash. SealDoc calcola sia un digest SHA-256, il valore a cui la richiesta RFC 3161 vincola la Time Stamping Authority, sia un digest SHA-384, che identifica il record nel registro delle prove. L’hash è un’impronta del contenuto. Se cambia anche un solo byte del documento dopo il calcolo dell’hash, l’impronta non corrisponde più. L’hash è conservato separatamente dal documento, così documento e impronta possono essere confrontati tra loro in qualsiasi momento futuro.
Una registrazione della catena di custodia. Ogni azione compiuta sul documento dopo la creazione viene registrata (accesso, conversione, archiviazione, reperimento) con l’identità di chi agisce, il timestamp e l’indirizzo IP, in un log di audit resistente alle manomissioni.
Insieme, questi tre elementi rispondono alle domande che pongono i procedimenti legali: questo documento esisteva in questa forma in questo momento, è stato modificato da allora, e chi lo ha gestito.
La questione pratica
La questione conta di più in queste circostanze: settori regolamentati, transazioni di alto valore, lunghi periodi di conservazione, fatture contestate, o qualsiasi contesto in cui una controparte possa avere interesse a contestare l’integrità dei tuoi registri.
Per questi casi d’uso, la distanza tra “abbiamo la fattura” e “possiamo dimostrare che la fattura è autentica” è reale, e la sola conformità del formato non la colma.
L’approccio più pratico è integrare il livello di prova nel momento in cui il documento viene creato, anziché a posteriori. Un timestamp RFC 3161 e una catena di hash aggiunti al momento della generazione non costano nulla al momento dell’audit. Aggiungerli a posteriori, o cercare di sostenere che i registri esistenti bastano anche senza, è più difficile.
SealDoc aggiunge il livello di prova a ogni documento elaborato nella pipeline: un timestamp RFC 3161 richiesto per impostazione predefinita a una Time Stamping Authority indipendente nell’UE, una catena di custodia SHA-256 sulle fasi di elaborazione, un registro delle prove SHA-384 sul record, e un Legal Evidence Pack, su richiesta, che raccoglie entrambi in un unico archivio verificabile.