Il tuo messaggio è stato inviato.
Elaboreremo la vostra richiesta e vi ricontatteremo al più presto.
Il modulo è stato inviato con successo.
Ulteriori informazioni sono contenute nella tua casella di posta elettronica.
Seleziona la lingua
24 agosto 2026
10 minuti di lettura

I requisiti tedeschi in materia di fatturazione elettronica possono trasformare un processo di fatturazione ormai familiare in un progetto IT improvvisamente molto più complesso. Se il vostro ERP funziona già bene, l’ultima cosa che vorreste è doverlo ricostruire da zero solo per supportare un altro formato di fattura.
Ecco perché inizierei da ciò che hai già a disposizione. Alcuni sistemi ERP sono in grado di generare fatture elettroniche strutturate tramite moduli integrati, API o componenti specifici per paese. Altri invece producono ancora PDF standard e richiedono un ulteriore passaggio di conversione. Una volta chiarita la situazione del proprio sistema, diventa molto più semplice scegliere una configurazione ZUGFeRD che soddisfi i requisiti senza apportare modifiche superflue al processo di fatturazione di base.

Architetto visionario, Dmitry colma il divario tra innovazione grezza e fattibilità commerciale. Supervisiona la roadmap tecnologica dell'azienda, assicurandosi che ogni soluzione sia costruita su uno stack che risolva un problema aziendale immediato.
ZUGFeRD è un formato ibrido di fattura elettronica. Una fattura ZUGFeRD combina un documento PDF/A-3 leggibile dall'utente con un file XML strutturato incorporato che i software di contabilità possono elaborare direttamente.
Il file XML contiene dati di fatturazione definiti, quali le informazioni relative al venditore e all’acquirente, le voci di fattura, i codici taxe, i totali, i dettagli di pagamento e i riferimenti. Per la fatturazione elettronica in Germania, la versione e il profilo ZUGFeRD selezionati sono importanti tanto quanto il file stesso.
ZUGFeRD prevede cinque profili principali, oltre al profilo di riferimento XRECHNUNG, che si differenziano sia per l’ambito dei dati che per l’utilizzo normativo. Per una tipica implementazione B2B tedesca basata sulla norma EN 16931, di solito inizierei con il profilo EN 16931 per poi passare al profilo EXTENDED quando il processo aziendale richiede dati strutturati aggiuntivi.
| Pazienti | Cosa comprende | Situazione in Germania |
|---|---|---|
| MINIMO | Informazioni di base su acquirente, venditore, totali e imposte | Non riconosciuta come fattura UStG completa |
| BASIC WL | Informazioni contabili a livello di intestazione senza righe di fattura | Non riconosciuta come fattura UStG completa |
| BASIC | Sottoinsieme della norma EN 16931 per fatture più semplici | Riconosciuta come fattura UStG completa |
| EN 16931, precedentemente denominata COMFORT | Modello completo di fattura base secondo la norma EN 16931 | Riconosciuta come fattura UStG completa e come soluzione principale per la fatturazione elettronica standard conforme alle norme UE |
| ESTESO | EN 16931 più dati aggiuntivi per processi aziendali più complessi | Riconosciuta come fattura UStG completa |
| CALCOLO | Profilo di riferimento basato sui requisiti XRechnung di KoSIT | Rilevante soprattutto nei casi in cui si applicano i requisiti di XRechnung, in particolare nel settore B2G |
FeRD raccomanda espressamente la norma EN 16931 per le fatture elettroniche conformi alle disposizioni dell'UE. Anche il Ministero federale delle finanze tedesco afferma che ZUGFeRD, a partire dalla versione 2.0.1, è in grado di soddisfare i requisiti tedeschi in materia di fatturazione elettronica, ad eccezione dei livelli MINIMUM e BASIC-WL.
Pertanto, la scelta del profilo dovrebbe avvenire in una fase iniziale. Scegliere, ad esempio, il profilo “MINIMUM” solo perché contiene gli importi di base non rende il documento una fattura elettronica tedesca conforme.
Non considererei questa come una regola secondo cui ogni fattura tedesca debba utilizzare lo standard ZUGFeRD. L'ambito di applicazione dipende comunque dalla transazione. Le fatture B2C, alcune transazioni esenti, le fatture di importo modesto e altri casi particolari possono seguire regole diverse.
Un file PDF standard contiene informazioni destinate principalmente alla lettura da parte dell'utente. Una fattura elettronica strutturata fornisce inoltre al software di contabilità campi definiti e leggibili da un computer.
Una persona potrebbe vedere:
Una fattura strutturata distingue i valori sottostanti, in modo che il software possa identificare quale importo corrisponda alla base imponibile, all'IVA, al totale lordo e all'importo da pagare.
Questa distinzione consente ai sistemi ERP e contabili di elaborare le fatture senza doverne ricostruire il significato a partire dal testo o dall'impaginazione del PDF.
Prima di implementare un convertitore, verificare se l’ERP offre già funzioni di fatturazione elettronica specifiche per paese, API o moduli documentali.
Di solito ci sono tre percorsi:
Gli ambienti SAP, ad esempio, possono avvalersi di funzionalità specifiche per ciascun Paese tramite SAP Document and Reporting Compliance. Altri sistemi ERP o personalizzati potrebbero richiedere l’utilizzo di middleware o di un servizio di conversione separato.
Un convertitore autonomo risulta quindi la soluzione più sensata quando manca un supporto nativo adeguato o quando la modifica dell'applicazione di fatturazione principale comporterebbe rischi inutili per il progetto.
Nel caso di un processo basato su PDF, il flusso di conversione può essere il seguente:
Ove possibile, i dati ERP strutturati rappresentano una fonte migliore rispetto ai valori ricavati dal PDF. I formati JSON, XML, CSV, i record di database o i dati API preservano il significato dei campi della fattura e riducono gli errori di interpretazione.
La creazione del file XML richiede una corretta mappatura semantica. Il convertitore deve identificare il significato di ciascun valore della fattura e inserirlo nel campo strutturato corrispondente.
Il prezzo è un dato semplice. Altri campi richiedono invece un contesto più ampio: gli identificativi del venditore e dell’acquirente, il tipo di fattura, le categorie fiscali, i codici unità, gli sconti, gli addebiti, i riferimenti, i termini di pagamento, le informazioni sulla consegna e il dettaglio dell’IVA possono tutti influire sul formato XML.
| Importo della fattura | Termine della norma EN 16931 |
|---|---|
| Numero della fattura | BT-1 |
| Data di emissione | BT-2 |
| Valuta | BT-5 |
| Nome del venditore | BT-27 |
| Nome dell'acquirente | BT-44 |
| Importo netto della linea | BT-131 |
| Totale IVA esclusa | BT-109 |
| Totale IVA | BT-110 |
| Totale IVA inclusa | BT-112 |
| Importo dovuto | BT-115 |
La maggior parte del lavoro di implementazione riguarda questo modello di dati e la relativa convalida. Il sistema deve mappare correttamente i dati di origine, creare un file XML valido, convertirlo in formato PDF/A-3 e garantire la coerenza tra entrambe le rappresentazioni.
Controllerei la fattura in diverse fasi:
Ad esempio:
Il convertitore dovrebbe calcolare e confrontare questi valori, anziché copiare stringhe formattate dal PDF.
Consiglierei inoltre di verificare il file PDF/A-3 finale dopo l'incorporamento dell'XML. La fase di creazione del pacchetto modifica il documento, quindi limitarsi a controllare il PDF di origine non garantisce la correttezza del risultato finale.
Prima dell'invio, confronterei il numero della fattura, le date, le parti, la valuta, gli importi delle voci, le informazioni fiscali, i totali, i dati di pagamento e i riferimenti tra il file PDF e quello XML.
Possiamo aiutarvi a valutare la vostra attuale configurazione ERP, definire il flusso di dati di fatturazione più adeguato e implementare la fatturazione elettronica integrandola con i sistemi che già utilizzate.
Il tuo messaggio è stato inviato.
Elaboreremo la vostra richiesta e vi ricontatteremo al più presto.