Articoli di approfondimento
Informatica
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:
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!