Le
fatture elettroniche in formato XML e gli aspetti tecnico-informatici
La normativa italiana prevede, dal 2019, l'obbligo generato di fatturazione elettronica in formato XML. Tutte le fatture (salve rarissime eccezioni) devono pertanto venire emesse in formato XML, seguendo le specifiche tecniche definite dall'Agenzia delle Entrate ed inviate al Sistema di Interscambio (SDI), sempre gestito dall'Agenzia delle Entrate, che provvede poi a recapitarla in formato elettronico al destinatario.
Tralasciando in questa sede le specifiche tecniche, che esigerebbero una copiosa trattazione in separata sede, mi soffermo in questo breve articolo su alcuni aspetti particolari, che è importante avere chiari per potere poi gestire correttamente, da un punto di vista informatico, la fattura elettronica.
Il primo, che può sembrare banale, è la codifica, che deve essere UTF-8. Talvolta mi è invece capitato, paradossalmente, di riscontrare XML non conformi, aihmé puntualmente accettati da SDI. Questo purtroppo succede perché evidentemente sia taluni produttori software da un lato, che SOGEI stessa dall'altro lato, presumibilmente leggono i files XML come un qualsiasi file di testo, ossia senza utilizzare strumenti appositamente creati per gestire i files XML, e quindi qualche errore del file non viene sempre intercettato e può dunque sfuggire.
Quindi, a prescindere dall'accettazione del file da parte di SDI, è fondamentale che il file sia comunque a norma, con codifica caratteri UTF-8 e che rispetti tutte le regole previste per i files XML. Questo perché il file XML contenente la fattura viene recapitato tale e quale dal destinatario, e quindi il sofware del cliente potrebbe avere difficoltà a leggere un file XML non conforme (che SDI avrebbe dovuto peraltro scartare).
Un altro aspetto che viene spesso dibattuto è la necessità o meno della firma digitale. La normativa fiscale prevede un espresso obbligo di apposizione della firma digitale solo per le fatture emesse nei confronti della Pubblica Amministrazione. E per le altre? Per le fatture emesse a soggetti privati è tecnicamente e legalmente possibile inviare a SDI fatture prive di firma digitale. Ma (c'è sempre un ma!)... la mancanza della firma digitale può creare non pochi problemi, in base alla vigente normativa IVA, sia italiana che comunitaria.
La direttiva 2010/45/UE, recepita in Italia con la legge n. 228/2012, ha infatti novellato il comma 3 dell’art. 21 del DPR 633/1972, che ora prevede testualmente:
"Il soggetto passivo assicura l'autenticità dell'origine, l'integrità del contenuto e la leggibilità della fattura dal momento della sua emissione fino al termine del suo periodo di conservazione; autenticità dell'origine ed integrità del contenuto possono essere garantite mediante sistemi di controllo di gestione che assicurino un collegamento affidabile tra la fattura e la cessione di beni o la prestazione di servizi ad essa riferibile, ovvero mediante l'apposizione della firma elettronica qualificata o digitale dell'emittente o mediante sistemi EDI di trasmissione elettronica dei dati o altre tecnologie in grado di garantire l'autenticità dell'origine e l'integrità dei dati."
È quindi necessario che la fattura elettronica assicuri in ogni caso l'autenticità all'origine, l'integrità del contenuto e la leggibilità. In base al dettato normativo questi requisiti possono essere soddisfatti, alternativamente, con sistemi di controllo di gestione che permettano di correlare la fattura alla cessione di beni o alla prestazione di servizi a cui si riferisce la fattura, mediante sistemi di trasmissione elettronica dei dati oppure appunto a mezzo di firma digitale.
Nell'ambito tecnico le posizioni degli "addetti ai lavori" non sono univoche sul ruolo di SDI, diversi esperti ritengono ad esempio che il Sistema di Interscambio (SDI) dell'Agenzia delle Entrate da solo non sia sufficiente per potere essere considerato un vero e proprio sistema "EDI di trasmissione elettronica dei dati", o un sistema equivalente, in quanto trattandosi di un servizio pubblico generalizzato non sarebbe integrabile con (proprie) tecnologie aggiuntive per pervenire a garantire la richiesta autenticità e l'integrità richiesti.
Forse discutibile, forse (sarebbe auspicabile!) andrebbe aggiornato il comma 3 dell'Art. 21 in seguito all'entrata in vigore dell'obbligo generalizzata di fatturazione elettronica, per comprendere espressamente SDI, forse... ma intanto i dubbi restano. E con essi i possibili rischi.
Premesso che in questi pochi anni di fatturazione elettronica non si è ancora sviluppata una giurisprudenza consolidata, appare pertanto chiaro che l'apposizione della firma digitale risolve a monte tutti i possibili problemi che possono sorgere ai sensi del nuovo comma 3 dell'Art. 21 del DPR 633/1972. Per questo è sicuramente raccomandato che le fatture elettroniche vengano sempre firmate digitalmente anche nella fatturazione tra soggetti privati (del resto quasi tutti i servizi di fatturazione elettronica forniscono di serie questo servizio, ed il motivo è quello appena spiegato).
Un terzo aspetto che vorrei sottolineare è che le specifiche tecniche del tracciato della fattura elettronica XML permettono di allegare uno o più documenti, ad esempio in formato PDF. Mi capita tuttavia spesso di notare, sempre con un certo stupore, come tale campo venga impropriamente utilizzato nella prassi operativa da alcune (tante) software houses per riportare la fattura PDF analogica. Questo, a mio modo di vedere, non ha alcun senso. Si va infatti ad allegare una fattura, analogica e come tale priva di qualsiasi valore legale, alla fattura ufficiale in formato XML. Al riguardo vorrei sottolineare alcuni aspetti.
Il primo è che per leggere il file PDF allegato occorre essere comunque in grado di leggere il file XML, all'interno del quale la fattura analogica in formato PDF è contenuta: ne consegue, evidentemente, che ciò non semplifica affatto le cose ai destinatari "poco tecnologici". In poche parole, se il destinatario riesce a leggere il file XML, non ha bisogno di ricevere gli stessi dati in un ulteriore documento PDF allegato; se non è in grado di leggere il file XML, non è neppure in grado di aprire il PDF allegato. Punto.
Tra parantesi potrebbe paradossalmente verificarsi invece la situazione opposta, in cui il software di ricezione si limita a leggere i dati "ufficiali" del tracciato XML e non legga gli allegati. Raramente, ma capita con alcuni software, magari di stampo un po' vecchiotto.
In secondo luogo il documento PDF non è un documento ufficiale, quindi non ha alcuna utilità concreta. Se è necessario indicare alcuni dati aggiuntivi questo può essere effettuato utilizzando opportunamente gli appositi campi facoltativi del tracciato XML, come il campo "causale", che è un campo descrittivo, solo per fare un esempio.
Terzo punto, le fatture elettroniche in formato XML vengono generalmente gestite direttamente dagli uffici amministrativi e dai commercialisti: il cliente finale, nella maggior parte dei casi vedrà pertanto solamente i dati che il sistema gestionale in uso rende disponibile, spesso si tratta dei dati contenuti nel file XML, magari stampati su un layout aziendale o standard (nella migliore delle ipotesi la fattura analogica in formato PDF viene stampata in coda alla fattura vera e propria, altre volte per vederla occorre cliccare appositamente sugli allegati).
Quarta cosa, i files allegati occupano inutilmente spazio di archiviazione nei vari servizi che normalmente sia mittente che destinatario utilizzano per la gestione della fatturazione elettronica.
Di conseguenza, è totalmente inutile ed inopportuno, almeno a mio modo di vedere. A cosa serve allora la possibilità di allegare un documento PDF alla fattura elettronica XML? Semplice, serve ad allegare altri documenti, diversi dalla fattura, come possono essere un certificato di collaudo, una dichiarazione di conformità, e qualsiasi altro documento di supporto correlato ai beni o ai servizi a cui si riferisce la fattura.
Per le autofatture può invece essere utilizzato per allegare - qui sì - la fattura di acquisto originale: in questo caso infatti abbiamo due documenti differenti, l'autofattura e la fattura originale - magari estera e quindi analogica - a cui l'autofattura si riferisce, questo permette di avere nello stesso XML tutti gli elementi relativi all'acquisto e di potere portare tutto in conservazione sostitutiva.
Tuttavia al di là di questa particolare ipotesi, allegare la stessa identifica fattura in formato PDF è secondo me totalmente privo di qualsiasi logica.
Chiusa la parentesi sui files allegabili alle fatture elettroniche, il quarto punto che vorrei trattare ora è l'intestazione del file XML. Per la creazione dei files XML molta attenzione va infatti sempre prestata ai campi di testata, qui di seguito riporto un esempio:
Infine un punto molto importante da conoscere a livello tecnico è la modalità di decodifica delle fatture elettroniche, soprattutto quando sono firmate digitalmente.
La firma digitale, infatti, può tecnicamente essere apposta in maniera diversa sui files, con busta o senza busta, ed il file firmato può essere stato convertito o meno in formato Base64.
Mi riferirò con un esempio utilizzando OpenSSL, in quanto è uno strumento Open Source disponibile su tutte le piattaforme, chiaramente questo va poi adattato allo specifico tool che concretamente si utilizza per l'estrazione del contenuto di un file firmato digitalmente.
A seconda di come è concretamente apposta la firma digitale nel file P7M, i comandi con OpenSSL sono normalmente questi:
oppure:
a seconda di come è firmato tecnicamente il file P7M.
Tuttavia, l'utilizzo di uno solo di questi due comandi non è sufficiente ad estrarre correttamente gli XML da tutti i files P7M, perché come scritto sopra potrebbero eventualmente essere stati codificati in formato Base64. In questo caso vanno allora prima decodficati da Base64, poi va estratto l'XML dal P7M decodificato (sempre con uno dei due metodi visti sopra, a seconda della codifica del file).
OpenSSL permette eventualmente con un unico comando di effettuare entrambe le operazioni (è sufficiente aggiungere dopo il comando openssl: base64 -d), tenendo sempre presente che la decodifica da Base64 va naturalmente effettuata solo sui files codificati in Base64 e non genericamente su tutti.
Quindi finora abbiamo visto due tipi di codifica dei files firmati (con Base64 oppure no) e due tipi di firma digitale. Quindi 4 casistiche diverse in totale, visto che queste situazioni sono combinabili tra loro.
Per chi usa OpenSSL per l'estrazione c'è inoltre una casistica ulteriore: l'eventuale carattere di fine riga non conforme. In alcuni casi infatti ho riscontrato files P7M che presentano un carattere di fine riga, generalmente CR+LF (ossia quello utilizzato come fine riga in ambiente Windows), che OpenSSL potrebbe non gestire, in questo caso vanno eliminati i caratteri CR+LF dal file prima di procedere all'estrazione.
Soprattutto per chi non è abituato a lavorare con files firmati digitalmente, complice anche la carenza di informazioni ufficiali al riguardo da parte dell'Agenzia delle Entrate, l'estrazione della fattura elettronica XML dal file P7M potrebbe quindi non essere immediata, mentre conoscendo questi piccoli "trucchi del mestiere" tutto diventa più agevole perché si sa già in partenza come procedere.
Certo, sarebbe naturalmente preferibile che SDI permettesse di scaricare (anche) il solo file XML già decodificato (l'eventuale firma digitale apposta viene tra l'altro già verificata da SDI), ma poiché così non è, anche per una casistica tutto sommato semplice come quella di un file XML, bisogna invece andare a gestire tutto il processo di estrazione e di decodifica dei files firmati digitalmente.
Alla fine di tutto restano naturalmente da gestire tutti i casi di files XML non conformi, ossia fatture elettroniche a tutti gli effetti sbagliate nella forma e nella struttura (per quanto riguarda gli errori nel contenuto... ci sarebbe da scrivere un libro... ma esula dagli aspetti tecnici che mi ero proposta di affrontare con questo breve articolo, ma basta vedere alcuni fornitori che indicano il totale documento diverso dal castelletto IVA, oppure il totale da pagare diverso dal totale documento, condizioni di pagamento non conformi, talvolta perfino assenti, appoggi bancari errati, solo per citare alcune delle casistiche che si riscontrano con una frequenza ancora impressionante... qui è davvero meglio stendere un velo pietoso...).
Mi riferisco in particolare all'espressa violazione delle regole di base dei files XML, come ad esempio l'encoding diverso da UTF-8, oppure la presenza nel file XML di caratteri che non sono comunque conformi allo standard UTF-8, l'intestazione del file XML errata e/o non conforme alla struttura del file, solo per citarne alcuni. In questo caso si tratta di veri e propri errori nel file XML, che avrebbe dovuto di conseguenza essere scartato, ma che SDI ha invece, inspiegabilmente, accettato. Questi errori possono creare chiaramente problemi con i diversi componenti di lettura dei files XML, e quindi sui software gestionali utilizzati dai destinatari (clienti) delle fatture, che potrebbero non riuscire a leggere questi files, in quanto si tratta di files XML non conformi alle regole di base previste per i files XML.
Sperando che prima o poi vengano risolte queste problematiche ancora aperte in modo che queste fatture vengano finalmente scartate a monte da SDI (come si usa dire, la speranza è l'ultima a morire), nel frattempo bisogna in qualche modo gestire anche queste anomalie, che non dovrebbero esserci, ma che in realtà ci sono. E qui... la realtà supera davvero la fantasia!