Blog

PDF/A-3 uitgelegd: en hoe u controleert of uw bestand echt conform is

PDF/A-3 is het enige PDF/A-profiel dat legaal ingesloten bijlagen kan bevatten, de basis voor Factur-X / ZUGFeRD e-facturatie. Verschillen, controles en een gratis dual-engine validator.

PDF/A is de bewaarvariant van PDF: de garantie dat een document in 2050 op dezelfde manier rendert als in 2026. Er zijn vier grote profielen (PDF/A-1, 2, 3, 4), elk met subconformiteitsniveaus. Daarvan is PDF/A-3 het profiel dat EU e-facturatie stilletjes mogelijk maakt, en het enige breed gebruikte profiel dat willekeurige bestandsbijlagen binnen de bewaarwrapper toestaat.

Als u facturen, regulatory filings of een proces met “PDF + gestructureerde data” raakt, is PDF/A-3 de specificatie die u tegenkomt. Dit is wat het is, hoe het verschilt van de verwante profielen, en hoe u controleert of een bestand werkelijk conform is.

De PDF/A-familie in één alinea

Profiel ISO-deel Jaar Bepalende functie
PDF/A-1 19005-1 2005 Eerste bewaarprofiel. Geen transparantie, geen JavaScript, fonts ingesloten.
PDF/A-2 19005-2 2011 Voegt JPEG2000, transparantie en laagondersteuning toe. Betere printgetrouwheid.
PDF/A-3 19005-3 2012 Voegt ingesloten bestandsbijlagen toe. De wrapper voor Factur-X / ZUGFeRD.
PDF/A-4 19005-4 2020 Moderne revisie; schoner conformiteitsmodel, geen b versus a split.

Elk profiel heeft subniveaus:

  • b (basic): visuele getrouwheid blijft behouden. Iedereen kan het lezen; er zijn geen garanties voor semantische content.
  • a (accessible): structure tagging plus Unicode-mapping. Screenreaders kunnen de tekst in de juiste volgorde extraheren.
  • u (Unicode): Unicode-mapping, maar geen volledige structuur. Tussenvariant.
  • e / f (alleen PDF/A-4): voegt engineering-3D-content en volledige formulieren toe.

“PDF/A-3b” betekent dus: bewaarprofiel 3 (staat bijlagen toe), basic niveau (geen accessibility tagging vereist). Dat is de meest gebruikte variant in facturatie.

Wat bijzonder is aan PDF/A-3

PDF/A-1 en PDF/A-2 verbieden willekeurige ingesloten bestanden. De redenering: een bewaar-PDF moet zelfvoorzienend zijn; een ingesloten data.xlsx kan onafhankelijk van de PDF verouderen en de bewaargarantie breken.

PDF/A-3 versoepelt die regel expliciet onder een nauw afgebakende voorwaarde: elk ingesloten bestand moet worden gedeclareerd met een AFRelationship-attribuut dat zegt hoe het bestand zich verhoudt tot de zichtbare PDF-content. Geldige waarden zijn Source, Data, Alternative, Supplement, Unspecified. De PDF-declaratie moet de bijlage ook opnemen in de /AF array en XMP-metadata uitgeven die het ingesloten bestand beschrijft.

Met andere woorden: PDF/A-3 zegt “u mag dingen insluiten, maar alleen als u exact declareert wat ze zijn en hoe ze horen bij wat de mens ziet”. Die declaratie maakte PDF/A-3 het voertuig voor e-facturatie: de mensleesbare factuur gaat in de PDF, de machineleesbare EN 16931 CII XML gaat in de bijlage, en AFRelationship="Alternative" verklaart dat beide alternatieve representaties van dezelfde factuur zijn.

Waar PDF/A-3 in productie wordt gebruikt

  • Factur-X (Frankrijk, B2B verplicht vanaf 2026): PDF/A-3 + CII XML, met de XMP namespace urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#.
  • ZUGFeRD 2.x (Duitsland, ontvangst verplicht in 2025): PDF/A-3 + CII XML, met de XMP namespace urn:zugferd:pdfa:CrossIndustryDocument:invoice:2p0#.
  • Engineering CAD-bewaring: PDF/A-3 met een ingesloten native CAD-bestand. De PDF is de rendering; de CAD is de bron.
  • Regulatory submissions: PDF/A-3 met ingesloten XML-data (FDA submissions, ESEF financial reports voor EU-listed issuers).

In al deze gevallen is de wrapper niet alleen een container. Het is een contract dat zegt: “deze PDF en dit ingesloten bestand zijn hetzelfde document, en beide moeten valideren”.

Hoe u controleert of een bestand PDF/A-3-conform is

De officiële conformance checker is veraPDF (verapdf.org), onderhouden door de PDF Association. Deze implementeert de ISO 19005-3-regelset. Als veraPDF “Pass — PDF/A-3b” rapporteert, is dat het sterkste signaal dat één engine kan geven.

Maar een “Pass” van één engine is niet de auditwaardige standaard (Waarom twee PDF/A-validators beter zijn dan één behandelt de redenering). Het auditwaardige patroon is twee onafhankelijke engines draaien en het bestand pas conform noemen wanneer beide slagen.

Voor een e-factuurbestand hebt u nog een tweede soort engine nodig: Mustang (mustangproject.org), de de-facto Factur-X / ZUGFeRD-checker die de ingesloten CII XML valideert tegen EN 16931 Schematron. PDF/A-3-conformiteit alleen is niet genoeg; de ingesloten XML moet ook geldige EN 16931 zijn, anders weigert het AP-systeem aan de ontvangende kant de factuur.

De meeste teams installeren Java, zetten de veraPDF CLI op, installeren Mustang en schrijven een shellscript dat outputs samenvoegt. Dat werkt, maar het geeft frictie.

validator draait alle drie in de browser:

  1. veraPDF: officiële referentie, PDF/A-3-conformiteit.
  2. gPdf’s Rust+WASM edge engine: onafhankelijke herimplementatie, second-opinion bevestiging.
  3. Mustang: EN 16931 CII XML Schematron, voor ingesloten e-factuurdata.

Drop het bestand; alle drie draaien parallel en rapporten komen naast elkaar terug. JSON is downloadbaar als QA-bewijs. Geen login, geen quota.

Waar u echt op let in een PDF/A-3-rapport

Wanneer u de validator draait en een van de engines een fout rapporteert, clusteren failures meestal rond een paar gebieden:

  • Metadata van ingesloten bestand ontbreekt: de /AF array ontbreekt, of het ingesloten bestand staat er niet in.
  • AFRelationship ontbreekt of is verkeerd: voor e-facturatie hoort dit Alternative te zijn; Source / Data is de standaard waar veel PDF-pakketten op terugvallen.
  • XMP namespace ontbreekt of is verkeerd: Factur-X en ZUGFeRD hebben specifieke namespace-URI’s; één typfout laat de controle falen.
  • Fonts zijn niet gesubset of niet ingesloten: PDF/A vereist dat alle glyphs die in het document worden gebruikt met het font zijn ingesloten. Edgecase: een fontreferentie die wel is gedeclareerd maar nooit echt wordt gebruikt, kan nog steeds falen.
  • Output intent ontbreekt: PDF/A vereist dat een kleurintentie (sRGB of een ander ICC-profiel) wordt gedeclareerd, zelfs wanneer het document alleen zwart-witte tekst bevat.
  • Documentmetadata is incompleet: /Title, /Producer, /CreationDate moeten aanwezig zijn in de document info dictionary.

Elke fout heeft een specifieke specificatiesectie waar de validator in het rapport naar verwijst. U lost dit op bij de bron. Als u via gPdf genereert, handelt de API deze punten automatisch af en is de validator uw publieke bewijsstuk.

TL;DR

PDF/A-3 = PDF/A-2 plus de mogelijkheid om legaal willekeurige bestanden in te sluiten. Die mogelijkheid maakt EU e-facturatie werkbaar: de mensleesbare factuur plus de gestructureerde EN 16931 CII XML in één bewaarwrapper. Conformiteit vereist dat de wrapper voldoet aan PDF/A-3 en dat de ingesloten XML voldoet aan EN 16931. Beide moeten slagen voordat u live gaat.

Genereer via POST /api/v1/e-invoice/render. Verifieer op validator. Drie engines (veraPDF + gPdf edge + Mustang), één upload, gratis.