Wat is PDF/A-3 en waarom het ertoe doet voor e-facturatie

Heb je de afgelopen twee jaar in de buurt van Europese e-facturatie gewerkt, dan ben je de term PDF/A-3 vast tegengekomen, alsof iedereen al weet wat het betekent. De meeste artikelen gaan ervan uit dat de lezer het verschil kent tussen pdf, PDF/A en PDF/A-3, en stappen er dan overheen. De verschillen zijn niet academisch. Ze bepalen of een factuur die je vandaag verstuurt, in 2036 nog te openen, te verifiëren en juridisch geldig is.

Hier de versie die wij graag hadden gelezen toen we begonnen.

PDF, PDF/A, PDF/A-3: drie verschillende dingen

Een gewone pdf is een presentatieformaat. Het kan alles bevatten wat een ontwerper wil: externe lettertype-referenties, JavaScript, ingebedde video, links naar externe bronnen. Die flexibiliteit is geweldig voor marketingbrochures en rampzalig voor archieven. Een pdf uit 2005 kan in een viewer uit 2025 al anders renderen omdat een lettertype is vervangen, een externe bron 404 geeft, of een leveranciersuitbreiding is afgevoerd.

PDF/A (ISO 19005) is een strikte deelverzameling van pdf, ontworpen om voor altijd identiek te renderen. Het verbiedt de dynamische functies. Elk lettertype moet ingebed zijn. Elk kleurprofiel moet zelfvoorzienend zijn. Geen JavaScript, geen externe inhoud, geen versleuteling. Het resultaat is een bestand dat decennia later gegarandeerd te openen en visueel identiek is.

PDF/A-3 is de derde herziening van die standaard, gepubliceerd in 2012. Eén ding werd gewijzigd: het laat toe willekeurige bijlagen in te bedden in de pdf. Eerdere versies (PDF/A-1, PDF/A-2) stonden enkel bijlagen toe die zelf PDF/A-conform waren. PDF/A-3 schrapt die beperking. Je kunt nu een XML-bestand, een CSV, een JSON-document of wat dan ook als gestructureerde bijlage inbedden.

Die ene wijziging is wat moderne e-facturatie mogelijk maakte.

Waarom e-facturatie precies dit nodig had

Een conforme Europese e-factuur moet twee dingen tegelijk zijn:

1. Machinaal leesbaar. Het boekhoudsysteem van de afnemer moet regelitems, btw-tarieven en betaalcondities zonder menselijke tussenkomst kunnen inlezen.
2. Menselijk leesbaar, jarenlang. De fiscale wetgeving in de meeste EU-landen vereist archivering van de factuur in een vorm die een menselijke auditor kan openen en lezen, gedurende periodes tussen 7 en 10 jaar.

Een puur UBL XML-bestand voldoet aan de eerste eis maar faalt op de tweede. Een pure pdf voldoet aan de tweede maar niet aan de eerste. Een PDF/A-3 met ingebedde UBL voldoet aan beide, in één tamper-evident container, en de visuele laag is bit-identiek aan de gestructureerde laag.

Dit is de architectuur achter zowel Factur-X (de Frans/Duitse hybride factuurstandaard) als ZUGFeRD (zijn Duitse voorganger). Beide zijn PDF/A-3 met een specifieke XML-bijlage op een specifieke locatie met een specifieke bestandsnaam. Strip de marketingnamen weg en wat overblijft is “PDF/A-3, plus een afspraak over welke XML je erin stopt”.

Wat PDF/A-3 je niet geeft

PDF/A-3 is een archiefformaat. Het is geen compliance-certificaat, en het is geen handtekening. Drie dingen die het uitdrukkelijk niet doet:

• Het valideert de ingebedde XML niet. Je kunt een gemankeerde UBL in een PDF/A-3 stoppen en het bestand passeert nog steeds de PDF/A-3-validatie. Het formaat garandeert enkel de container, niet de inhoud.
• Het bewijst niet wanneer het bestand is gemaakt. Een PDF/A-3-bestand kan opnieuw worden opgeslagen, opnieuw getimestampt en opnieuw worden verzonden zonder enig spoor achter te laten. Wil je bewijzen “deze factuur bestond op deze datum”, dan heb je een RFC 3161-tijdstempel bovenop nodig.
• Het garandeert geen aflevering. Conformiteit met het formaat en conformiteit met een nationaal mandaat (Peppol, KSeF, Chorus Pro) zijn verschillende problemen. PDF/A-3 is noodzakelijk maar niet voldoende.

Daarom levert de SealDoc-pipeline een PDF/A-3 plus een RFC 3161-tijdstempel plus een evidence pack met manifest-hashes. Elke laag beantwoordt een andere vraag, en een echte audit zal alle drie vragen.

Veelvoorkomende manieren waarop pipelines PDF/A-3 verkeerd doen

We zien dezelfde vijf fouten terugkeren in klant-pipelines:

1. Halfslachtig geconverteerde pdf’s. Een library claimt “PDF/A-3 uitvoer” maar slaat het inbedden van systeemlettertypen over, die op de machine van de auditor anders renderen.
2. Verkeerde bijlage-relatie. PDF/A-3 onderscheidt Source, Data, Alternative, Supplement en Unspecified. Factur-X eist Alternative. Veel embedders kiezen standaard Unspecified en het bestand zakt voor strikte validatie.
3. Ontbrekende XMP-metadata. PDF/A vereist zelfbeschrijvende metadata in XMP. Een bestand zonder de verplichte pdfaid:part- en pdfaid:conformance-sleutels is technisch geen PDF/A-3, ongeacht structuur.
4. Kleurprofiel-drift. Een PDF/A-3 moet elke gebruikte kleurruimte declareren. Pipelines die willekeurige RGB-afbeeldingen zonder ingebed profiel doorlaten, produceren stilletjes non-conforme bestanden.
5. Bestaande pdf opnieuw renderen. Sommige pipelines rasteriseren de invoer-pdf voordat ze opnieuw XML inbedden. Visueel werkt dat, maar het vernietigt de doorzoekbare tekstlaag en breekt de toegankelijkheid.

Je kunt elk van deze punten checken met onze publieke validator op /check. Bestand erin, verdict in seconden, geen registratie nodig. Faalt een bestand, dan vertelt het rapport precies welke clausule van welke spec geschonden is.

Wanneer PDF/A-3 de juiste keuze is (en wanneer niet)

PDF/A-3 is de juiste keuze wanneer je jarenlang een menselijk leesbare kopie van een gestructureerd document moet bewaren én je beide lagen in één container wil. Dat dekt e-facturatie, e-bonnen, gestructureerde contracten en in toenemende mate e-tickets en douanedocumenten.

Het is de verkeerde keuze voor kortlevende documenten (een leveringsbon die binnen een week vervalt), voor documenten waar de gestructureerde payload het enige is dat telt (pure EDI), of waar de menselijk leesbare laag puur decoratief is en nooit geaudit zal worden.

Voor iedereen anders in EU-B2B in 2026 is PDF/A-3 het formaat. De technische details hierboven zijn waarom het werkt, en waarom een verkeerde implementatie stilletjes bestanden produceert die de interne QA passeren en pas drie jaar later op het bureau van de auditor falen.