PDF/A is de archiefvariant van PDF: de belofte dat een document in 2050 hetzelfde rendert als in 2026. Er zijn vier hoofdprofielen (PDF/A-1, 2, 3, 4), elk met conformance levels. PDF/A-3 is het profiel dat Europese e-invoicing praktisch mogelijk maakt, en het enige breed gebruikte PDF/A-profiel dat willekeurige bestandsbijlagen in de archief-wrapper toestaat.

Als u werkt aan invoices, regulatory filings of een workflow met “PDF + structured data”, komt PDF/A-3 langs. Hieronder staat wat het betekent, hoe het verschilt en hoe u echte compliance controleert.

De PDF/A-familie in één overzicht

Profile	ISO part	Year	Belangrijkste kenmerk
PDF/A-1	19005-1	2005	Eerste archiefprofiel. Geen transparency, geen JavaScript, fonts embedded.
PDF/A-2	19005-2	2011	Voegt JPEG2000, transparency en layer support toe. Betere print fidelity.
PDF/A-3	19005-3	2012	Voegt embedded file attachments toe. Wrapper voor Factur-X / ZUGFeRD.
PDF/A-4	19005-4	2020	Moderne revisie; schoner conformance model, geen `b` vs `a` split.

De subniveaus:

b (basic): visuele trouw blijft behouden, zonder semantische garanties.
a (accessible): structure tagging en Unicode mapping voor screen readers.
u (Unicode): Unicode mapping zonder volledige structuur.
e / f (alleen PDF/A-4): engineering 3D content en full forms.

“PDF/A-3b” betekent dus: archiefprofiel 3 met toegestane attachments, basic level zonder verplichte accessibility tagging. Dat is de gebruikelijke variant voor facturatie.

Wat PDF/A-3 bijzonder maakt

PDF/A-1 en PDF/A-2 verbieden willekeurige embedded files. De redenering: een archief-PDF moet self-contained zijn; een bijlage zoals data.xlsx kan los van de PDF verouderen en de archiefbelofte breken.

PDF/A-3 versoepelt die regel onder een strikte voorwaarde: elk embedded file moet AFRelationship declareren, waarmee de relatie tot de zichtbare PDF-content wordt uitgelegd. Geldige waarden zijn Source, Data, Alternative, Supplement, Unspecified. De PDF moet de bijlage ook opnemen in de /AF array en XMP metadata over het attached file emitten.

Met andere woorden: PDF/A-3 laat bijlagen toe, maar eist dat u precies zegt wat ze zijn en hoe ze horen bij wat de gebruiker ziet. Dat maakte het de drager voor e-invoicing: de menselijk leesbare invoice staat in de PDF, de machineleesbare EN 16931 CII XML in de attachment, en AFRelationship="Alternative" zegt dat beide dezelfde invoice voorstellen.

Waar PDF/A-3 in productie zit

Factur-X (Frankrijk, B2B gefaseerd verplicht vanaf 2026): PDF/A-3 + CII XML, met XMP namespace urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#.
ZUGFeRD 2.x (Duitsland, ontvangst verplicht sinds 2025): PDF/A-3 + CII XML, met XMP namespace urn:zugferd:pdfa:CrossIndustryDocument:invoice:2p0#.
Engineering CAD archival: PDF/A-3 met native CAD file als attachment. PDF is de rendering, CAD is de source.
Regulatory submissions: PDF/A-3 met XML payloads, zoals FDA submissions of ESEF financial reports van EU-beursgenoteerde bedrijven.

In al deze gevallen is de wrapper niet alleen een container. Het is een contract: deze PDF en dit attached file zijn hetzelfde document en moeten allebei validate.

Hoe PDF/A-3-compliance te controleren

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

Maar een single-engine “Pass” is geen audit-grade standard (Why two PDF/A validators are better than one legt dit uit). Het robuuste patroon is twee independent engines draaien en het bestand alleen compliant noemen als beide slagen.

Voor een e-invoice is er nog een laag nodig: Mustang (mustangproject.org), de de-facto checker voor Factur-X / ZUGFeRD. Mustang valideert de embedded CII XML tegen EN 16931 Schematron. PDF/A-3 conformance alleen is niet genoeg; de attached XML moet ook valid EN 16931 zijn, anders weigert het AP system van de ontvanger de invoice.

Veel teams installeren Java, zetten veraPDF CLI op, installeren Mustang en schrijven een shell script om outputs te combineren. Het werkt, maar het is frictie.

validator draait alle drie in de browser:

veraPDF: official reference, PDF/A-3 conformance.
gPdf Rust+WASM edge engine: independent re-implementation, second opinion.
Mustang: EN 16931 CII XML Schematron voor embedded e-invoice payloads.

Drop het bestand, drie engines draaien parallel en de rapporten komen naast elkaar terug. JSON is downloadbaar als QA evidence. Geen login, geen quota.

Waar u in het rapport op let

Failures zitten meestal hier:

Embedded file metadata missing: geen /AF array, of embedded file staat er niet in.
AFRelationship missing or wrong: voor e-invoice moet dit Alternative zijn; veel PDF libraries gebruiken standaard Source of Data.
XMP namespace missing or wrong: Factur-X en ZUGFeRD hebben specifieke namespace URI’s; één teken fout faalt.
Fonts not subsetted or not embedded: PDF/A vereist dat alle gebruikte glyphs met de font embedded zijn.
Output intent missing: PDF/A vereist een colour intent (sRGB of ander ICC profile), zelfs bij zwart-witte tekst.
Document metadata incomplete: /Title, /Producer, /CreationDate moeten in de information dictionary staan.

Het rapport verwijst meestal naar de relevante spec section. Los het op bij de bron; als u met gPdf genereert, handelt de API dit automatisch af en is validator uw publieke bewijs.

TL;DR

PDF/A-3 = PDF/A-2 + de mogelijkheid om willekeurige bestanden legaal te embedden. Dat maakt EU e-invoicing werkbaar: human-readable invoice + structured EN 16931 CII XML in één archival wrapper. Zowel PDF/A-3 wrapper als attached XML moeten slagen.

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