Conoscenze · Fatturazione elettronica
Validare la fattura elettronica e leggere correttamente il rapporto di verifica
Quando una fattura elettronica emessa dal Suo software viene respinta, il Suo team deve capire dal rapporto di verifica quale campo ha generato la segnalazione e chi può correggerlo.
Mostriamo come leggere un rapporto di verifica e in quali punti la validazione va inserita nel Suo software.
Che cosa viene verificato nella validazione di una fattura elettronica
Un validatore verifica una fattura elettronica in successione rispetto a tre set di regole e registra ogni scostamento in un rapporto di verifica.
Schema XML della sintassi
Una fattura elettronica secondo la EN 16931 è disponibile in una di due sintassi, UBL o UN/CEFACT CII. Tutte le specifiche d’uso più comuni si basano su queste due sintassi, ad esempio XRechnung, ZUGFeRD e Peppol BIS Billing 3.0.
Lo schema XML della sintassi stabilisce quali elementi sono ammessi, in quale ordine devono comparire e quale tipo di dato hanno.
Gli errori di schema non hanno un ID della regola. Il parser XML li segnala con codici propri, ad esempio cvc-complex-type.2.4.a per un elemento in una posizione in cui lo schema non lo prevede.
In ZUGFeRD un file CII è incorporato in un PDF. Il validatore verifica la parte XML. In caso di scostamenti rispetto alla parte visiva, è questa parte a fare fede, secondo la circolare del Ministero federale delle Finanze (BMF-Schreiben) del 15 ottobre 2025 sull’introduzione della fattura elettronica obbligatoria.
Regole di business della EN 16931
Le regole di business controllano i dati di una fattura elettronica alla ricerca di errori logici, ad esempio se i campi obbligatori sono compilati e se i totali sono coerenti tra loro. Il Comitato europeo di normazione (CEN) pubblica queste regole come file Schematron su GitHub, rispettivamente per UBL e per CII.
Dal prefisso dell’ID della regola si riconosce il tipo di verifica. Le regole con BR e un numero verificano i campi obbligatori e la loro numerosità, BR-CO verifica calcoli e dipendenze tra campi, BR-CL verifica gli elenchi di codici e BR-DEC i decimali degli importi. Regole come BR-S, BR-AE o BR-IC verificano i dati relativi alle singole categorie IVA.
I file del CEN contengono inoltre regole specifiche della sintassi. Le regole con il prefisso UBL-CR, ad esempio, segnalano un avviso quando un file UBL contiene elementi che non appartengono al modello di dati della EN 16931.
Regole di XRechnung e Peppol BIS Billing 3.0
XRechnung e Peppol BIS Billing 3.0 sono specifiche d’uso della EN 16931, in termini tecnici CIUS (Core Invoice Usage Specification). Prescrivono campi aggiuntivi e integrano la EN 16931 con regole proprie. Una CIUS non può introdurre nuovi campi di dati.
Le regole di XRechnung iniziano con BR-DE e provengono dall’Ufficio di coordinamento per gli standard IT (Koordinierungsstelle für IT-Standards, KoSIT). Peppol BIS Billing 3.0 aggiunge regole con i prefissi PEPPOL-EN16931 e PEPPOL-COMMON nonché regole specifiche per paese.
L’identificativo della specifica in BT-24 stabilisce quale specifica d’uso si applica al file. Il validatore della KoSIT seleziona in base a questo identificativo lo scenario di verifica adatto. Un identificativo errato od obsoleto può quindi far sì che il file venga verificato rispetto ad altre regole o respinto.
Che cosa una validazione non verifica
Un validatore non riconosce se l’aliquota IVA è adeguata alla prestazione o se la descrizione della prestazione è sufficiente.
Secondo il Ministero federale delle Finanze tedesco, tutte le indicazioni obbligatorie ai fini IVA devono trovarsi nella parte strutturata della fattura elettronica. Un semplice rinvio a un allegato con la descrizione della prestazione non è sufficiente. Un nome articolo come «vedi allegato» in BT-153 supera comunque la validazione, perché nessuna regola valuta il contenuto di questo campo.
La KoSIT e il Forum per la fattura elettronica in Germania (Forum elektronische Rechnung Deutschland, FeRD) hanno pubblicato una tabella che associa alle indicazioni obbligatorie previste dalla legge tedesca sull’IVA i relativi campi BT. Sulla base di questa tabella può stabilire quali indicazioni obbligatorie il Suo software dovrebbe tutelare con propri controlli di plausibilità.
Struttura di un rapporto di verifica
Ogni voce del rapporto di verifica contiene di norma quattro informazioni.
ID della regola
L’ID della regola, come BR-CO-15 o BR-DE-2, rimanda alla regola nella documentazione del rispettivo set di regole.
Livello di gravità
Un validatore contrassegna ogni segnalazione come errore o come avviso. Nelle regole Peppol gli errori si chiamano fatal. Un avviso da solo di norma non porta al rifiuto. Alcuni validatori emettono inoltre indicazioni, cioè raccomandazioni per un’implementazione corretta senza influenza sul risultato. Alla fine del suo rapporto il validatore della KoSIT raccomanda di accettare o respingere il documento.
Peppol introduce spesso nuove regole dapprima come avviso e le eleva a errore in una release successiva. Con la versione 3.0.21, ad esempio, le regole PEPPOL-COMMON-R052 e PEPPOL-COMMON-R053 sono passate da avvisi a errori, come riportato nelle release notes di Peppol BIS Billing 3.0.
Posizione
La posizione è un’espressione XPath che punta all’elemento interessato nell’XML. Lo stesso numero BT si trova in UBL e in CII in punti diversi. L’importo della fattura IVA inclusa (BT-112) si trova in UBL nell’elemento cbc:TaxInclusiveAmount sotto cac:LegalMonetaryTotal, in CII nell’elemento ram:GrandTotalAmount sotto ram:SpecifiedTradeSettlementHeaderMonetarySummation.
Nelle regole che confrontano più campi, la posizione punta spesso a un elemento di livello superiore. Il valore che genera la segnalazione si trova allora tramite il testo del messaggio.
Testo del messaggio
Il testo del messaggio descrive la regola e indica per lo più i numeri BT coinvolti. Il messaggio relativo a BR-CO-15, ad esempio, afferma che l’importo della fattura IVA inclusa (BT-112) deve corrispondere alla somma dell’importo della fattura IVA esclusa (BT-109) e dell’importo IVA (BT-110).
Dalla versione 3.0.21 i testi delle regole Peppol iniziano con l’ID della regola.
Analizzare i rapporti di verifica nell'ordine giusto
Un rapporto di verifica lungo risale spesso a poche cause.
-
Correggere gli errori di schema
Finché il file non rispetta lo schema, i risultati delle regole di business sono poco significativi o mancano del tutto. Corregga quindi per prima cosa gli errori di schema nell'esportazione e poi validi di nuovo il file.
-
Raggruppare le voci per ID della regola
Un errore nella mappatura può comparire in ogni riga della fattura. Una fattura con 40 righe genera allora 40 voci relative alla stessa regola, che risalgono a un'unica causa. Analizzi quindi il rapporto per ID della regola.
-
Riconoscere gli errori conseguenti
Un elemento mancante può violare più regole contemporaneamente. Se manca il riepilogo IVA (BG-23), il validatore segnala ad esempio BR-CO-18 e in aggiunta regole della categoria IVA interessata, come BR-S-01. Corregga prima la causa e validi di nuovo, prima di trattare singolarmente le segnalazioni rimanenti.
-
Dal numero BT al proprio modello di dati
Il numero BT collega il rapporto di verifica al Suo software. Mantenga un'associazione tra ogni numero BT e il campo del database, il campo del modulo nella Sua interfaccia e la responsabilità. La responsabilità stabilisce se un errore lo corregge il Suo team o il Suo cliente, ad esempio quando mancano dati anagrafici.
-
Valutare e documentare gli avvisi
Decida per ogni avviso se correggerlo o accettarlo consapevolmente, e documenti la decisione. A ogni nuova release verifichi se un avviso accettato viene elevato a errore.
Cause di errore tipiche per gruppo di regole
Il gruppo di regole indica spesso già in quale punto del Suo software va applicata la correzione.
Errori di schema senza ID della regola
La causa sta nell’ordine degli elementi, nel namespace o in un tipo di dato errato nell’esportazione. La correzione va applicata nella funzione di esportazione, una volta per tutti i clienti.
BR con numero
La causa sta in un campo obbligatorio non mappato o vuoto nei dati anagrafici. La correzione va applicata nella mappatura o al campo obbligatorio nell’interfaccia.
BR-CO e BR-DEC
La causa sta in totali, arrotondamenti, sconti e maggiorazioni a livello di documento. La correzione va applicata nella logica di calcolo della creazione delle fatture.
BR-CL
La causa sta in un codice obsoleto o proprietario, ad esempio per unità di misura o paesi. La correzione va applicata agli elenchi di codici nel Suo software.
BR-S, BR-AE, BR-IC e altre categorie
Categoria IVA, aliquota e motivo di esenzione non sono coerenti tra loro. La correzione va applicata nella logica fiscale e nei dati anagrafici degli articoli.
UBL-CR
L’esportazione contiene elementi UBL al di fuori del modello di dati della EN 16931. La correzione va applicata nella funzione di esportazione.
BR-DE
Mancano i dati di contatto del venditore, i dati di pagamento o il riferimento dell’acquirente. La correzione va applicata per lo più ai dati anagrafici dei Suoi clienti.
PEPPOL-EN16931 e PEPPOL-COMMON
Manca l’indirizzo elettronico oppure un identificativo ha il formato errato. La correzione va applicata ai dati anagrafici e alla gestione degli ID Peppol.
Riferimento dell’acquirente mancante in XRechnung (BR-DE-15)
La regola BR-DE-15 segnala un riferimento dell’acquirente mancante in BT-10. Nelle fatture alla pubblica amministrazione vi si trova il Leitweg-ID dell’autorità. Per le fatture B2B, secondo il Ministero federale delle Finanze tedesco, ai fini IVA è sufficiente un segnaposto come «-», se il destinatario della fattura non indica un proprio identificativo. Il Suo software può quindi precompilare il campo per le fatture B2B con un segnaposto che i Suoi clienti possono sovrascrivere.
Differenze di arrotondamento nell’IVA (BR-S-09)
La regola BR-S-09 confronta l’importo IVA della categoria ad aliquota ordinaria con il prodotto di base imponibile e aliquota. Se il Suo software arrotonda l’IVA per riga e somma gli importi, il totale può discostarsene. Con molte righe lo scostamento può superare la tolleranza ammessa dalla regola. Calcoli quindi l’importo dell’imposta per categoria a partire da base imponibile e aliquota, come prescrive la regola.
Integrare la validazione nel Suo software
La validazione va inserita in cinque punti del Suo software e del Suo processo di sviluppo.
Prima dell’invio
Il Suo software dovrebbe validare ogni fattura elettronica subito dopo la creazione e bloccare l’invio in caso di errori. I Suoi clienti sanno farsene poco di un ID della regola o di un’espressione XPath. Traduca quindi le regole che i Suoi clienti possono correggere da soli in un’indicazione accanto al campo del modulo interessato. L’indicazione relativa a BR-DE-6, il numero di telefono del contatto del venditore in BT-42, può ad esempio essere «Indichi un numero di telefono per eventuali domande».
Gli errori che derivano dalla Sua mappatura o dalla Sua logica di calcolo non possono essere corretti dal cliente. Tali errori dovrebbero arrivare al Suo team come segnalazione interna.
Alla ricezione
Il Suo software dovrebbe validare anche le fatture elettroniche in entrata e mostrare il risultato accanto al documento. Conservi il file originale senza modifiche e il rapporto di verifica come documento separato accanto ad esso. Il Ministero federale delle Finanze tedesco richiede che almeno la parte strutturata di una fattura elettronica sia conservata integra nella sua forma originale.
Se una fattura passiva contiene errori, il Suo cliente può richiedere al mittente una fattura rettificata. Il Suo software può supportare questo passaggio, ad esempio con una richiesta al mittente già predisposta che contiene il rapporto di verifica.
Nei test automatizzati
Crei una raccolta di fatture di test che copra i Suoi tipi di fattura con i relativi codici, ad esempio 380 per una fattura e 384 per una fattura di rettifica. Copra inoltre ogni categoria IVA utilizzata dai Suoi clienti. A ciò si aggiungono sconti e maggiorazioni nonché ogni sintassi generata dal Suo software. Includa anche file volutamente errati e verifichi che il validatore li respinga.
Il validatore della KoSIT è un programma open source a riga di comando e può essere integrato in una pipeline di build. La KoSIT mette inoltre a disposizione una suite di test con fatture di esempio, adatta come punto di partenza per la Sua raccolta.
Dopo ogni aggiornamento dei set di regole
I set di regole cambiano anche senza un nuovo numero di versione. Per XRechnung 3.0.2 la KoSIT pubblica regolarmente bundle con correzioni di errori, l’ultimo nella versione del 31 agosto 2026. XRechnung 3.0 resta in vigore almeno fino al 31 luglio 2027.
La versione preliminare della specifica XRechnung 4.0 è stata pubblicata il 15 settembre 2026. Non è espressamente destinata all’uso in produzione, ma Le offre una prima panoramica delle funzionalità nuove e modificate. La versione finale dovrebbe essere pubblicata nella primavera del 2027 insieme ai componenti tecnici.
OpenPeppol pubblica regolarmente nuove release di Peppol BIS Billing 3.0, negli ultimi anni ogni volta a maggio e a novembre. La versione 3.0.21 è stata pubblicata il 20 maggio 2026 ed è vincolante dal 17 agosto 2026.
Pianifichi per ogni release una data fissa in cui validare la Sua raccolta di test rispetto alle nuove regole. Registri in ogni rapporto di verifica con quale versione del validatore e del set di regole è stato generato. Così potrà ricostruire un risultato anche quando le regole sono nel frattempo cambiate. Per il passaggio a XRechnung 4.0 il Suo ambiente di test dovrebbe poter verificare entrambe le versioni in parallelo.
Analizzare i rapporti di verifica su tutti i clienti
Se il Suo software genera fatture elettroniche per molti clienti, conviene analizzare i rapporti di verifica su tutti i clienti. Se lo stesso ID della regola compare improvvisamente presso molti clienti, la causa sta probabilmente nella mappatura o in un nuovo set di regole. Se compare solo presso un cliente, la causa sta più probabilmente nei suoi dati anagrafici.
Validazione con InvoiceRails
Può implementare completamente in proprio i passaggi descritti in questo articolo. L’impegno iniziale è contenuto, quello permanente no: set di regole, elenchi di codici e configurazioni di verifica cambiano più volte all’anno e ogni modifica deve confluire nei Suoi test, nel Suo invio e nella Sua pianificazione delle release.
Validazione, invio e manutenzione dei set di regole possono quindi essere affidati anche a un Peppol Access Point certificato come InvoiceRails.
Validatore di fatture elettroniche per verifiche singole
Il validatore di fatture elettroniche gratuito di InvoiceRails verifica file XML in UBL e CII nonché fatture PDF ibride, senza registrazione. Riconosce automaticamente sintassi, versione e profilo, tra cui XRechnung, Peppol BIS Billing 3.0, ZUGFeRD, Factur-X e altri profili della EN 16931. Valida poi il file rispetto allo schema XML e alle regole Schematron e di business del profilo riconosciuto. Il rapporto di verifica può essere scaricato come PDF o condiviso tramite link, ad esempio quando il Suo supporto discute con un cliente una fattura respinta.
L’API di InvoiceRails nel Suo software
InvoiceRails è il Peppol Access Point certificato OpenPeppol di fino data services. Il Suo software integra InvoiceRails tramite un’API REST e invia e riceve tramite essa fatture elettroniche per un numero qualsiasi di clienti, su richiesta in white label.
L’API offre la validazione come endpoint dedicato, anch’esso con riconoscimento automatico del profilo. Il Suo software può così verificare le fatture elettroniche subito dopo la creazione. Ogni segnalazione nella risposta contiene ID della regola, livello di gravità, testo del messaggio e posizione come XPath. Il Suo software può salvare l’ID della validazione con la fattura e richiamare di nuovo il risultato per almeno 90 giorni.
InvoiceRails valida ogni file che il Suo software invia tramite Peppol, anche senza questa chiamata. Il Suo software deve verificare in anticipo quali formati supporta un destinatario.
InvoiceRails verifica anche le fatture elettroniche in entrata e consegna al Suo software il file originale insieme ai dati della fattura estratti. Un webhook comunica al Suo software ogni modifica dello stato di consegna.
Il Suo software continua a occuparsi dell’associazione dei campi del Suo modello di dati, delle indicazioni comprensibili nella Sua interfaccia e dei controlli di plausibilità per le indicazioni obbligatorie che nessuna regola copre.
