PDF/A-3B e ZUGFeRD: il mio PDF di fattura elettronica è davvero conforme? (veraPDF)

ZUGFeRD è una fattura ibrida: un PDF leggibile dalle persone più l'XML leggibile dalle macchine al suo interno. La parte PDF deve essere una particolare variante di archiviazione – PDF/A-3. Proprio qui nascono la maggior parte dei malintesi.

> Risposta breve: Affinché un PDF sia davvero PDF/A-3(-B), devono tra l'altro essere incorporati tutti i caratteri, essere presente un OutputIntent/profilo colore ICC e adeguati metadati PDF/A. Un validatore come veraPDF lo verifica, ma non ripara nulla. Se il PDF di partenza non è conforme (ad es. caratteri non incorporati), aiuta solo una vera conversione – oppure utilizzate una XRechnung pura.

Cosa richiede PDF/A-3

PDF/A è concepito affinché un documento venga visualizzato in modo identico su qualsiasi computer e per molti anni. A tal fine valgono regole rigorose, le più importanti:

1. Tutti i caratteri incorporati – il file deve contenere direttamente i dati dei caratteri e non può fare affidamento sul fatto che il lettore abbia installato ad es. Arial.
2. OutputIntent / profilo colore ICC – il file deve stabilire come vengono riprodotti i colori.
3. Metadati PDF/A-XMP – la marcatura come PDF/A-3.

L'inciampo frequente: caratteri non incorporati

I sistemi gestionali e di fatturazione più datati generano spesso PDF che rimandano a caratteri di sistema come Arial o Arial Bold, ma non li incorporano. Un file di questo tipo è già non conforme a PDF/A – e questo non si può sanare aggiungendo solo l'XML ZUGFeRD e i metadati PDF/A.

Validare non è convertire

Un punto importante: veraPDF valida soltanto, non converte. Un validatore segnala "non conforme", ma da un file non conforme non ne crea uno conforme. Per generare davvero un PDF/A-3 serve un vero passaggio di conversione, che incorpori i caratteri e aggiunga un profilo colore (ad es. con Ghostscript o la libreria di riferimento ZUGFeRD Mustangproject).

Ciò che è sempre corretto: l'XML

Indipendentemente dal contenitore PDF, la parte decisiva e giuridicamente rilevante è l'XML strutturato. In TaxLayer questo viene validato integralmente rispetto allo standard di verifica KoSIT e alla EN 16931 (0 errori). I dati della fattura stessi sono quindi corretti e conformi – la questione PDF/A riguarda solo l'involucro esterno.

Come arrivare in sicurezza all'obiettivo

• Variante A – esportare PDF/A dal sistema: se il vostro sistema gestionale può produrre la fattura come PDF/A (con caratteri incorporati), il file ZUGFeRD generato da esso è conforme.
• Variante B – utilizzare una XRechnung pura: con la XRechnung (XML puro) viene meno completamente il contenitore PDF; la questione della conformità PDF/A non si pone.

Conclusione

PDF/A-3 è più di un'etichetta: richiede caratteri incorporati, un profilo colore e i metadati corretti. Chi proviene da un sistema più datato, esporta al meglio direttamente in PDF/A – oppure punta su XRechnung, dove il contenitore PDF non ha alcun ruolo.

---

L'XML della fattura elettronica è in TaxLayer sempre validato EN 16931 e KoSIT. Domande sulla conformità PDF/A? Scrivete a info@landauer.de.