# Validatori ZUGFeRD: cosa testare prima di inviare una fattura ibrida

- Date: 2026-04-20
- Modified: 2026-08-29
- Verificato: 15 agosto 2026
- Reading time: 3 min di lettura

Guida pratica 2026 per validare fatture ZUGFeRD e Factur-X: regole XML, controlli PDF/A-3, scelta del profilo, errori comuni e combinazioni utili di validator.

> Verificato rispetto a Risorse Factur-X FNFE-MPE, Schemi XML UN/CEFACT.

Questa guida è per i team che generano ZUGFeRD o Factur-X e si chiedono se “il PDF si apre” significhi davvero che la fattura è pronta per essere inviata.

Non basta. Una fattura ibrida realmente utilizzabile richiede più di un PDF leggibile: l’XML incorporato deve corrispondere al profilo giusto, i dati obbligatori devono esserci, i totali devono quadrare e anche il contenitore PDF deve soddisfare le aspettative archivistiche del formato.

## Cosa dovrebbe controllare davvero un validator

- L’XML incorporato è presente e può essere letto correttamente dal contenitore PDF.
- I dati fattura sono conformi a EN 16931 e al profilo ZUGFeRD o Factur-X selezionato.
- Totali, ripartizioni IVA, unità e date sono coerenti tra loro.
- Il file PDF soddisfa i vincoli PDF/A-3 attesi per un workflow di fattura ibrida.
## Usa più di un tipo di validazione

Un flusso solido combina di solito almeno due livelli. Prima valida le regole business e l’XML. Poi controlla il contenitore PDF/A-3 e il packaging del file incorporato. Se il canale del destinatario applica controlli propri, consideralo come terzo gate e non come unico test.

Per questo i team combinano spesso un validator di fattura consapevole di ZUGFeRD con un validator PDF/A come [veraPDF](https://verapdf.org/) per il contenitore documentale.

## Workflow di validazione consigliato

- Genera la fattura ZUGFeRD o Factur-X da dati sorgente già rivisti.
- Esegui una validazione a regole contro il profilo target e le aspettative EN 16931.
- Esegui il controllo PDF/A-3 sul documento finale, non su un PDF bozza senza XML incorporato.
- Apri il documento in un viewer capace di mostrare il contenuto strutturato e confronta i campi chiave con la fattura sorgente.
- Solo dopo invia via e-mail, portale o PEPPOL in base al processo del destinatario.
## Errori comuni e cosa significano di solito

- Il PDF si apre normalmente, ma l’XML manca, è danneggiato o non è allegato come previsto.
- L’XML è leggibile tecnicamente, ma campi obbligatori o identificativi di profilo sono errati.
- Totali riga, imponibili e importi IVA non si riconciliano dopo estrazione o mapping.
- Il documento sembra corretto a un revisore umano ma fallisce il controllo PDF/A-3 perché il contenitore ibrido è incompleto o non conforme.
## Fonti ufficiali e primarie

- [Pagina FeRD del pacchetto ZUGFeRD 2.5.2 / Factur-X 1.09.2](https://www.ferd-net.de/publikationen-produkte/publikationen/detailseite/zugferd-252-english).
- [Configurazione del validatore KoSIT per le regole EN 16931 e XRechnung](https://github.com/itplr-kosit/validator-configuration-xrechnung).
- [Note di supporto KoSIT per il contesto XRechnung](https://xeinkauf.de/xrechnung/supporthinweise/).
- [Progetto veraPDF per la validazione PDF/A](https://verapdf.org/).

## FAQ

### Aprire il PDF basta a dimostrare la conformità ZUGFeRD?

No. Un PDF leggibile dimostra solo che il livello visuale esiste. Non dimostra che l’XML incorporato sia presente, valido o coerente con il profilo scelto.

### Perché usare sia un validator fattura sia un validator PDF/A?

Perché controllano cose diverse. Il primo si concentra su regole e semantica della fattura, il secondo sulle aspettative di archiviazione e packaging del contenitore PDF.

### La validazione elimina la necessità di revisione umana?

No. La validazione è essenziale, ma la revisione umana resta necessaria per problemi di qualità sorgente, errori di scelta profilo e questioni business che i controlli automatici non interpretano completamente.

## Riferimenti ufficiali

- [Risorse Factur-X FNFE-MPE](https://fnfe-mpe.org/factur-x/)
- [Schemi XML UN/CEFACT](https://unece.org/trade/uncefact/xml-schemas)