gPdf
Blog

PDF/A-3 spiegato: come verificare che il file sia davvero conforme

PDF/A-3 è il profilo PDF/A che consente allegati incorporati, base della fatturazione elettronica Factur-X / ZUGFeRD. Differenze, controlli e validatore gratuito a doppio motore.

gPdf Engineering
#pdf-a#conformita#archiviazione#fattura-elettronica

PDF/A è la variante archivistica di PDF: la garanzia che un documento venga riprodotto nel 2050 come nel 2026. Esistono quattro profili principali (PDF/A-1, 2, 3, 4), ciascuno con sotto-livelli di conformità. Tra questi, PDF/A-3 è il profilo che abilita silenziosamente la fatturazione elettronica nell’UE, ed è l’unico profilo di uso diffuso che consente allegati di file arbitrari dentro il contenitore archivistico.

Se lavorate con fatture, invii regolatori o qualsiasi processo “PDF + dati strutturati”, PDF/A-3 è la specifica che incontrerete. Ecco che cos’è, in cosa differisce dai profili vicini e come verificare che un file sia davvero conforme.

La famiglia PDF/A in un paragrafo

Profilo Parte ISO Anno Caratteristica distintiva
PDF/A-1 19005-1 2005 Primo profilo archivistico. Niente trasparenza, niente JavaScript, font incorporati.
PDF/A-2 19005-2 2011 Aggiunge JPEG2000, trasparenza e supporto ai livelli. Migliore fedeltà di stampa.
PDF/A-3 19005-3 2012 Aggiunge allegati di file incorporati. Il contenitore per Factur-X / ZUGFeRD.
PDF/A-4 19005-4 2020 Revisione moderna; modello di conformità più lineare, senza separazione b vs a.

Ogni profilo ha sotto-livelli:

  • b (basic): la fedeltà visiva è preservata. Chiunque può leggerlo, senza garanzie sul contenuto semantico.
  • a (accessible): tagging strutturale e mappatura Unicode. Gli screen reader possono estrarre il testo nell’ordine corretto.
  • u (Unicode): mappatura Unicode senza struttura completa. Una via intermedia.
  • e / f (solo PDF/A-4): aggiunge contenuti 3D di ingegneria e moduli completi.

Quindi “PDF/A-3b” significa: profilo archivistico 3 (consente allegati), livello basic (nessun tagging di accessibilità richiesto). È la variante più comune nella fatturazione.

Che cosa rende speciale PDF/A-3

PDF/A-1 e PDF/A-2 vietano file incorporati arbitrari. Il ragionamento è archivistico: un PDF destinato alla conservazione deve essere autosufficiente; un data.xlsx allegato potrebbe degradarsi indipendentemente dal PDF, rompendo la garanzia archivistica.

PDF/A-3 allenta esplicitamente quella regola a una condizione ben delimitata: ogni file incorporato deve dichiarare un attributo AFRelationship che spiega come il file si collega al contenuto visibile del PDF. I valori validi sono Source, Data, Alternative, Supplement, Unspecified. La dichiarazione PDF deve anche elencare l’allegato nell’array /AF ed emettere metadati XMP che descrivono il file allegato.

In altre parole, PDF/A-3 dice: “potete allegare elementi, ma solo dichiarando con precisione che cosa sono e come si collegano a ciò che vede la persona”. Questa dichiarazione ha reso PDF/A-3 il veicolo della fatturazione elettronica: la fattura leggibile da una persona resta nel PDF, l’XML CII EN 16931 leggibile dalle macchine sta nell’allegato e AFRelationship="Alternative" dichiara che sono rappresentazioni alternative della stessa fattura.

Dove si usa PDF/A-3 in produzione

  • Factur-X (Francia, B2B obbligatorio dal 2026 in avanti): PDF/A-3 + CII XML, con namespace XMP urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#.
  • ZUGFeRD 2.x (Germania, ricezione obbligatoria dal 2025): PDF/A-3 + CII XML, con namespace XMP urn:zugferd:pdfa:CrossIndustryDocument:invoice:2p0#.
  • Conservazione CAD per l’ingegneria: PDF/A-3 con file CAD nativo allegato. Il PDF è la resa visiva; il CAD è la sorgente.
  • Invii regolatori: PDF/A-3 con dati XML allegati (invii FDA, report finanziari ESEF per emittenti quotati nell’UE).

In tutti questi casi, il contenitore non è solo un contenitore: è un contratto che dice “questo PDF e questo file allegato sono lo stesso documento, ed entrambi devono superare le verifiche”.

Come verificare che un file sia conforme a PDF/A-3

Il controllore ufficiale di conformità è veraPDF (verapdf.org), mantenuto dalla PDF Association. Implementa l’insieme di regole ISO 19005-3; se veraPDF riporta “Pass — PDF/A-3b”, è il segnale più forte che possa dare un singolo motore.

Ma un “Pass” da un solo motore non è uno standard adatto a un audit (Why two PDF/A validators are better than one spiega il motivo). Il modello più robusto è eseguire due motori indipendenti e considerare il file conforme solo quando entrambi passano.

Per una fattura elettronica serve anche un secondo tipo di motore: Mustang (mustangproject.org), il controllore di fatto per Factur-X / ZUGFeRD, che verifica l’XML CII incorporato rispetto allo Schematron EN 16931. La conformità PDF/A-3 da sola non basta: anche l’XML allegato deve essere valido EN 16931, altrimenti il sistema AP ricevente rifiuterà la fattura.

Molti team installano Java, configurano la CLI di veraPDF, installano Mustang e scrivono uno script shell che mette insieme gli output. Funziona, ma introduce attrito.

validator esegue tutti e tre nel browser:

  1. veraPDF: riferimento ufficiale per la conformità PDF/A-3.
  2. motore edge Rust+WASM di gPdf: reimplementazione indipendente, conferma di seconda opinione.
  3. Mustang: Schematron EN 16931 CII XML, per i dati di fatturazione elettronica incorporati.

Caricate il file: i tre motori girano in parallelo e i report tornano affiancati. JSON scaricabile come evidenza QA. Nessun login, nessuna quota.

Che cosa controllare in un report PDF/A-3

Quando eseguite il validatore e uno dei motori segnala un errore, i problemi tendono a concentrarsi in poche aree:

  • Metadati del file incorporato mancanti: l’array /AF non è presente, oppure il file incorporato non è elencato.
  • AFRelationship mancante o errato: per una fattura elettronica dovrebbe essere Alternative; Source / Data è il valore predefinito di molte librerie PDF.
  • Namespace XMP mancante o errato: Factur-X e ZUGFeRD hanno URI specifici; basta un carattere sbagliato per fallire il controllo.
  • Font non sottoinsiemati o non incorporati: PDF/A richiede che tutti i glifi usati nel documento siano incorporati con il font. Caso limite: anche un riferimento a un font dichiarato ma mai realmente usato può fallire.
  • Intento di output mancante: PDF/A richiede la dichiarazione di un intento colore (sRGB o un altro profilo ICC), anche se il documento è solo testo nero su bianco.
  • Metadati del documento incompleti: /Title, /Producer, /CreationDate devono essere presenti nel dizionario informazioni del documento.

Ognuno di questi errori rimanda a una sezione precisa della specifica nel report del validatore. La correzione va fatta alla fonte; se generate tramite gPdf, l’API gestisce automaticamente questi dettagli e il validatore diventa la ricevuta pubblica della verifica.

TL;DR

PDF/A-3 = PDF/A-2 + capacità di incorporare legalmente file arbitrari. È questa capacità a rendere praticabile la fatturazione elettronica nell’UE: fattura leggibile da una persona + XML CII EN 16931 strutturato, in un unico contenitore archivistico. La conformità richiede che passino sia il contenitore PDF/A-3 sia l’XML allegato. Entrambi devono superare i controlli prima dell’invio.

Generate tramite POST /api/v1/e-invoice/render. Verificate su validator. Tre motori (veraPDF + edge gPdf + Mustang), un caricamento, gratuito.