PDF/A è la variante archivistica di PDF: la promessa che un documento verrà renderizzato nel 2050 come nel 2026. Esistono quattro profili principali (PDF/A-1, 2, 3, 4), ciascuno con livelli di conformità. PDF/A-3 è il profilo che rende possibile l’e-invoicing europeo, ed è l’unico profilo PDF/A di uso diffuso che permette allegati arbitrari dentro il wrapper d’archivio.

Se lavori con fatture, invii regolatori o qualunque workflow “PDF + structured data”, incontrerai PDF/A-3. Ecco cosa significa, come differisce dagli altri profili e come verificare la conformità reale.

La famiglia PDF/A in breve

Profilo	ISO part	Anno	Caratteristica
PDF/A-1	19005-1	2005	Primo profilo d’archivio. Niente transparency, niente JavaScript, font embedded.
PDF/A-2	19005-2	2011	Aggiunge JPEG2000, transparency e layer support. Migliore print fidelity.
PDF/A-3	19005-3	2012	Aggiunge embedded file attachments. Wrapper per Factur-X / ZUGFeRD.
PDF/A-4	19005-4	2020	Revisione moderna; conformance model più pulito, senza split `b` vs `a`.

I sotto-livelli:

b (basic): preserva la fedeltà visiva, senza garanzie semantiche.
a (accessible): structure tagging e Unicode mapping per screen reader.
u (Unicode): Unicode mapping senza struttura completa.
e / f (solo PDF/A-4): engineering 3D content e full forms.

“PDF/A-3b” significa: profilo archivistico 3 con allegati permessi, livello basic senza obbligo di tagging accessibile. È la variante più comune per la fatturazione.

Cosa rende speciale PDF/A-3

PDF/A-1 e PDF/A-2 vietano embedded files arbitrari. Il motivo è archivistico: un PDF d’archivio deve essere self-contained; un allegato come data.xlsx potrebbe degradarsi separatamente dal PDF e rompere la garanzia.

PDF/A-3 allenta la regola con una condizione stretta: ogni embedded file deve dichiarare AFRelationship, cioè il rapporto con il contenuto visibile del PDF. Valori validi: Source, Data, Alternative, Supplement, Unspecified. Il PDF deve anche elencare l’allegato nell’array /AF ed emettere XMP metadata sul file allegato.

In pratica: PDF/A-3 permette allegati, ma chiede di dichiarare esattamente cosa sono e come si collegano a ciò che vede l’utente. Questa dichiarazione è la base dell’e-invoicing: la fattura leggibile sta nel PDF, l’EN 16931 CII XML leggibile dalle macchine sta nell’allegato, e AFRelationship="Alternative" indica che sono due rappresentazioni della stessa fattura.

Dove vive PDF/A-3 in produzione

Factur-X (Francia, B2B obbligatorio progressivamente dal 2026): PDF/A-3 + CII XML, con XMP namespace urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#.
ZUGFeRD 2.x (Germania, ricezione obbligatoria dal 2025): PDF/A-3 + CII XML, con XMP namespace urn:zugferd:pdfa:CrossIndustryDocument:invoice:2p0#.
Archivio CAD engineering: PDF/A-3 con file CAD nativo allegato. Il PDF è il rendering, il CAD è la source.
Invii regolatori: PDF/A-3 con XML payloads allegati, come FDA submissions o ESEF financial reports di issuer UE.

In questi casi il wrapper non è solo un container. È un contract: PDF e file allegato rappresentano lo stesso documento e devono validare entrambi.

Come verificare la conformità PDF/A-3

Il checker ufficiale è veraPDF (verapdf.org), mantenuto dalla PDF Association. Implementa il rule set ISO 19005-3; se veraPDF riporta “Pass — PDF/A-3b”, è il segnale più forte che un singolo engine possa dare.

Ma un “Pass” single-engine non è audit-grade standard (Why two PDF/A validators are better than one spiega perché). Il pattern robusto è eseguire due independent engines e considerare il file conforme solo quando entrambi passano.

Per un’e-invoice serve anche Mustang (mustangproject.org), il checker de-facto per Factur-X / ZUGFeRD. Mustang valida il CII XML embedded contro EN 16931 Schematron. La conformità PDF/A-3 da sola non basta; anche l’XML allegato deve essere EN 16931 valido, altrimenti l’AP system del destinatario rifiuta la fattura.

Molti team installano Java, veraPDF CLI e Mustang, poi scrivono uno shell script che unisce gli output. Funziona, ma aggiunge attrito.

validator esegue tutti e tre nel browser:

veraPDF: reference ufficiale per PDF/A-3 conformance.
gPdf Rust+WASM edge engine: implementazione indipendente, second opinion.
Mustang: EN 16931 CII XML Schematron per embedded e-invoice payloads.

Trascina il file, i tre engine girano in parallelo e i report tornano affiancati. JSON scaricabile per QA evidence. Nessun login, nessuna quota.

Cosa guardare nel report

I failure ricadono spesso qui:

Embedded file metadata missing: manca l’array /AF, oppure il file embedded non è listed.
AFRelationship missing or wrong: per e-invoice deve essere Alternative; molte PDF libraries usano Source o Data di default.
XMP namespace missing or wrong: Factur-X e ZUGFeRD hanno URI specifici; un carattere errato basta per fallire.
Fonts not subsetted or not embedded: PDF/A richiede che tutti i glyphs usati siano embedded con il font.
Output intent missing: PDF/A richiede un’intenzione colore (sRGB o altro ICC profile), anche per testo nero su bianco.
Document metadata incomplete: /Title, /Producer, /CreationDate devono essere presenti nell’information dictionary.

Il report di solito punta alla sezione specifica della spec. Correggi alla fonte; se generi con gPdf, l’API gestisce questi dettagli e validator diventa la tua ricevuta pubblica.

TL;DR

PDF/A-3 = PDF/A-2 + possibilità di incorporare legalmente file arbitrari. È questa capacità che rende praticabile l’e-invoicing UE: fattura leggibile + XML CII EN 16931 strutturato in un unico archival wrapper. Devono passare sia il PDF/A-3 wrapper sia l’XML allegato.

Genera con POST /api/v1/e-invoice/render. Verifica su validator. Tre engine (veraPDF + gPdf edge + Mustang), un upload, gratis.