XRechnung, ZUGFeRD e BIS Billing 3.0: quali formati di fattura elettronica dovrebbe supportare il Suo software

La EN 16931 descrive un modello di dati semantico. Stabilisce quali informazioni contiene una fattura e come sono in relazione tra loro, ad esempio il numero di fattura come BT-1 o il riferimento dell’acquirente come BT-10. La norma in sé non è un formato di file.

Per la rappresentazione tecnica ammette due sintassi: UBL e UN/CEFACT CII. Entrambe rappresentano lo stesso modello semantico, ma si differenziano per nomi degli elementi e struttura. Un software che legge solo UBL non può elaborare automaticamente una fattura CII, anche se questa è conforme alla norma.

Per l’implementazione ciò determina l’onere di manutenzione. Due mappature parallele significano che ogni modifica delle regole deve essere recepita in due punti. Chi invece mappa una sola volta sul modello semantico della norma e da lì genera entrambe le sintassi, interviene in un solo punto per ogni modifica.

In ricezione, al contrario, il file in entrata viene prima mappato sul modello semantico e da lì trasferito nel Suo modello di dati.

Al di sopra della norma si trovano le declinazioni nazionali e specifiche delle reti, chiamate nello standard Core Invoice Usage Specification, in breve CIUS. Una CIUS restringe la norma. Rende obbligatori campi opzionali, ne esclude altri e porta con sé regole Schematron proprie. Le declinazioni che vanno oltre l’ambito della norma si chiamano Extension.

Indipendentemente da sintassi e declinazione, una fattura elettronica si presenta o come semplice file XML o come PDF/A-3 con un file XML incorporato. Per il secondo caso si è affermata l’espressione formato ibrido.

XRechnung è una CIUS della EN 16931 ed è curata dall’Ufficio di coordinamento per gli standard IT, in breve KoSIT. È disponibile in entrambe le sintassi. Non ha una componente visiva: il file è puro XML.

XRechnung è prescritto per le fatture all’amministrazione federale tedesca. La fattura viene indirizzata tramite il Leitweg-ID, indicato nel set di dati come riferimento dell’acquirente.

Il canale di presentazione dipende dal destinatario. Entrano in considerazione i portali ZRE e OZG-RE oppure un Peppol Access Point. Nel B2B il Leitweg-ID non ha alcun ruolo. Lì XRechnung è solo uno dei diversi profili ammessi.

Attualmente vale la versione 3.0.2. Per XRechnung 4.0, il recepimento della EN 16931 nella versione 2026, esiste già una versione preliminare. La versione finale di XRechnung 4.0 dovrebbe essere pubblicata nella primavera del 2027.

ZUGFeRD racchiude un file XML secondo CII in un PDF/A-3. La persona vede il PDF, mentre il software legge l’XML.

La specifica prevede diversi profili con un diverso volume di dati, da MINIMUM a EXTENDED.

MINIMUM e BASIC WL non contengono una fattura completa e non soddisfano la norma. A partire dal profilo EN 16931, nelle versioni precedenti chiamato COMFORT, la parte strutturata è conforme alla norma. Il Suo software dovrebbe leggere il profilo durante l’importazione e trattare separatamente i file con MINIMUM o BASIC WL, ad esempio tramite una verifica manuale.

Factur-X è tecnicamente in gran parte identico a ZUGFeRD.

ZUGFeRD è utile soprattutto quando i Suoi clienti fatturano a destinatari che continuano a controllare le fatture visivamente. Tuttavia, dal punto di vista giuridico fa fede solo l’XML incorporato. Se PDF e XML divergono, secondo la circolare del Ministero federale delle Finanze (BMF-Schreiben) del 15 ottobre 2025 prevalgono i dati della parte strutturata.

Un processo di approvazione che controlla solo il PDF può quindi approvare una fattura il cui contenuto determinante è diverso.

In fase di invio il Suo software dovrebbe generare PDF e XML dallo stesso set di dati, affinché non divergano. In ricezione dovrebbe costruire per la verifica una propria visualizzazione a partire dall’XML, invece di mostrare il PDF allegato. Anche il Ministero federale delle Finanze tedesco raccomanda di visualizzare autonomamente la parte XML.

Anche Peppol BIS Billing 3.0 è una CIUS della EN 16931, basata su UBL 2.1. OpenPeppol lo ha specificato come formato proprio per lo scambio di fatture e note di credito tramite la rete.

Oltre alle regole della norma porta con sé regole Schematron proprie. Un file può superare la verifica rispetto alla EN 16931 e fallire su una regola Peppol. Spesso si tratta di elenchi di codici o di campi che la rete definisce in modo più restrittivo rispetto alla norma.

La specifica viene sviluppata in versioni successive. Chi valida in proprio dovrebbe verificare che i propri set di regole siano aggiornati.

A più lungo termine Peppol si sta muovendo verso PINT, una base armonizzata a livello internazionale per profili di fattura al di fuori dell’Europa. Per l’implementazione in Germania ciò attualmente non cambia nulla.

Per queste fatture il Suo software deve essere in grado di generare XRechnung. Il Leitweg-ID del destinatario va inserito come campo obbligatorio nel set di dati della fattura e viene riportato nell’XRechnung come riferimento dell’acquirente (BT-10). Se manca o si trova nel campo sbagliato, il portale di ricezione respinge la fattura.

La legge richiede una fattura conforme alla EN 16931 e lascia libero il formato. Sono ammessi XRechnung, ZUGFeRD a partire dal profilo EN 16931 e anche Peppol BIS Billing. L’XML incorporato resta in ogni caso giuridicamente determinante. Se PDF e XML divergono, il destinatario potrebbe controllare dati diversi da quelli giuridicamente validi.

Dal 1° gennaio 2025 le imprese nazionali devono essere in grado di ricevere fatture elettroniche conformi alla EN 16931. Per una fattura elettronica conforme alla norma il mittente non ha quindi bisogno del consenso del destinatario, anche se quest’ultimo preferisce un determinato formato.

Le due parti devono accordarsi solo sul canale di trasmissione e sui formati al di fuori della norma. In pratica il canale concordato va quindi registrato nei dati anagrafici del singolo partner commerciale.

Oltre a Peppol BIS Billing 3.0, tramite la rete Peppol si possono trasmettere anche XRechnung e, da marzo 2025, ZUGFeRD come file ibrido. I tipi di documento che un destinatario ha registrato nel servizio di directory indicano quali formati accetta. Prima dell’invio il Suo software deve interrogare questa registrazione e scegliere il formato adatto. Per verifiche singole la ricerca ID Peppol lo mostra senza registrazione.

Nell’esercizio corrente il Suo software dovrebbe effettuare questa interrogazione automaticamente prima dell’invio, direttamente tramite i servizi di directory SML e SMP oppure tramite l’API del Suo Peppol Access Point. Su questa base viene individuato un formato supportato da entrambi e la fattura elettronica viene poi generata in tale formato.

Le fatture in entrata arrivano nel formato scelto dal mittente. Il Suo software dovrebbe quindi essere in grado di leggere entrambe le sintassi, UBL e CII, e quindi anche XRechnung in entrambe le varianti. A ciò si aggiungono ZUGFeRD e Factur-X come file ibridi e, non appena i Suoi clienti ricevono fatture dall’estero, i profili lì in uso.

Ogni file in entrata contiene un identificativo della declinazione utilizzata. In UBL si trova nell’elemento cbc:CustomizationID, in CII nel parametro di contesto della linea guida. Il Suo software dovrebbe leggere per prima cosa questo identificativo, perché da esso dipende quali regole di verifica si applicano e come il file viene trasferito nel Suo modello di dati.

Alcuni Peppol Access Point si occupano di questo passaggio al posto Suo. Verificano il file in entrata, estraggono i dati della fattura e li consegnano insieme al file originale come set di dati uniforme.

Il Suo software dovrebbe coprire completamente la ricezione prima dell’invio, quindi entrambe le sintassi e i formati ibridi, perché i Suoi clienti devono essere in grado di ricevere fatture elettroniche già oggi.

L’invio diventa obbligatorio per i Suoi clienti in due fasi. Dal 1° gennaio 2027 con un fatturato complessivo dell’anno precedente superiore a 800.000 euro e dal 1° gennaio 2028 per tutte le restanti operazioni B2B nazionali.

Chi inizia con la sintassi CII può generare XRechnung nella variante CII e ZUGFeRD. UBL diventa necessario non appena i destinatari nella rete Peppol si aspettano Peppol BIS Billing 3.0, perché questo formato presuppone UBL.

Tutte le indicazioni obbligatorie ai fini IVA devono trovarsi nella parte strutturata della fattura elettronica, in forma elaborabile automaticamente. Ciò vale anche per la descrizione della prestazione. Un rinvio a un allegato, a un documento di trasporto o a un link non sostituisce un campo obbligatorio. Il fondamento sono le FAQ del Ministero federale delle Finanze tedesco sulla fattura elettronica e la circolare del Ministero federale delle Finanze (BMF-Schreiben) del 15 ottobre 2025.

Il motivo risiede nella struttura della fattura elettronica. Nei formati ibridi come ZUGFeRD sono determinanti i dati nell’XML; il PDF è solo una visualizzazione. Un’indicazione visibile solo nel PDF quindi non conta.

Se un’indicazione obbligatoria manca nella parte strutturata, la fattura è considerata non regolare e la detrazione dell’IVA del destinatario può essere a rischio. I Suoi clienti se ne accorgono al più tardi quando i partner commerciali respingono le fatture per questo motivo.

Molti modelli di fattura riportano le indicazioni obbligatorie come blocchi di testo che compaiono solo nel PDF. Spesso ciò riguarda la descrizione della prestazione, ad esempio “secondo offerta 2026-114”, il periodo di prestazione nel piè di pagina della fattura e l’indicazione dell’inversione contabile (reverse charge).

Nel modello di dati ciascuna di queste indicazioni dovrebbe avere un proprio campo, da cui viene compilato l’XML. Il periodo di prestazione va nei campi del periodo di fatturazione (BG-14), l’indicazione di reverse charge nella categoria d’imposta con motivo di esenzione (BT-120 e BT-121).

La validazione tecnica verifica se i campi obbligatori della norma sono presenti e compilati in modo formalmente corretto. Non riconosce se una descrizione della prestazione è sufficiente ai fini IVA. Una fattura può quindi superare la verifica e contenere comunque un’indicazione obbligatoria in modo insufficiente.

Documenti di trasporto, prospetti delle ore e altri documenti che accompagnano la fattura possono essere incorporati come allegato nella fattura elettronica, nella EN 16931 tramite il gruppo dei documenti giustificativi aggiuntivi (BG-24). Ciò sostituisce l’invio separato e tiene fattura e documentazione insieme in un unico file.

Un’XRechnung viene verificata rispetto a due set di regole, le regole della EN 16931 e le regole aggiuntive della KoSIT. Per Peppol BIS Billing 3.0 vale lo stesso con le regole di OpenPeppol. Una verifica rispetto alla sola norma dice quindi solo in parte se il destinatario accetterà il file. Il Suo software dovrebbe verificare rispetto al set di regole della declinazione che il destinatario si aspetta.

KoSIT e OpenPeppol pubblicano regolarmente nuove versioni dei loro set di regole con elenchi di codici e regole Schematron aggiornati. Se il Suo software non mantiene aggiornati i set di regole, possono essere respinte fatture che finora venivano accettate. Il rifiuto arriva allora dal destinatario, ma la causa sta nel proprio set di regole obsoleto.

Per i test durante lo sviluppo, i singoli file possono essere verificati con il validatore di fatture elettroniche gratuito rispetto alla EN 16931 e alle regole Peppol. Per la verifica automatica in esercizio InvoiceRails offre la validazione anche tramite un’API, rispetto alla EN 16931 e a profili come XRechnung, ZUGFeRD e Peppol BIS Billing. Il rapporto di verifica distingue errori, avvisi e indicazioni.

Una mappatura si costruisce una volta, ma le regole di verifica che stanno dietro possono cambiare più volte all’anno. Il prossimo grande passaggio è già alle porte con XRechnung 4.0 e la EN 16931 nella versione 2026.

La versione 2026 si basa su UBL 2.5. Nelle implementazioni conformi UBL 2.5 potrà essere utilizzato solo quando il CEN avrà pubblicato un binding di sintassi aggiornato. Fino ad allora valgono i binding esistenti basati su UBL 2.1. I fornitori possono quindi preparare il passaggio, ma non ancora attuarlo.

Chi costruisce il collegamento in proprio si assume questa manutenzione in modo permanente. Ciò comprende mantenere aggiornate le mappature per entrambe le sintassi, gli elenchi di codici e le regole Schematron e seguire i piani di versione di KoSIT, FeRD, OpenPeppol e CEN. È fattibile, ma impegna tempo di sviluppo che viene a mancare al proprio prodotto.

In alternativa, la manutenzione dei formati può essere affidata a un Peppol Access Point. InvoiceRails, l’Access Point certificato OpenPeppol di fino data services, copre tramite un’API oltre 60 formati, tra cui XRechnung, ZUGFeRD e Factur-X, e aggiorna costantemente regole di validazione e formati.

I fornitori integrano invio e ricezione una sola volta e mettono la funzione a disposizione di un numero qualsiasi di loro clienti, su richiesta con il proprio marchio. La mappatura dei propri dati di fatturazione sull’interfaccia resta al fornitore, così come i campi obbligatori nel proprio modello di dati.

Come i fornitori di software portano in generale la fatturazione elettronica nel proprio prodotto è spiegato nell’articolo sulla fatturazione elettronica per i fornitori di software.