Een PDF voldoet aan PDF/A-3 of niet. Waarom zou je hetzelfde bestand dan door twee validators halen?

Omdat de praktijk minder zwart-wit is: de PDF/A-specificatie is groot genoeg dat twee correcte implementaties op randgevallen kunnen verschillen. In een auditwaardige workflow is een enkele “Pass” geel licht, geen groen licht.

PDF/A is geen enkel algoritme

PDF/A bestaat uit meerdere delen van ISO 19005: PDF/A-1, PDF/A-2, PDF/A-3 en PDF/A-4, met niveaus b, a, u, e en f. Daaronder ligt ook de basis-PDF-specificatie, ISO 32000. Samen zijn dat duizenden pagina’s normatieve tekst.

Verschillen ontstaan vaak bij:

Transparantie in PDF/A-2/3: toegestaan onder voorwaarden, maar de grenzen worden verschillend geïnterpreteerd.
ICC-kleurprofielen: verplicht, aanbevolen of onvoldoende hangt af van de engine.
Metadata van embedded files in PDF/A-3: AFRelationship, /AF-referenties en XMP moeten exact kloppen.
Font subsetting: CID-fonts en partial subsets leveren klassieke edge cases op.

Dat zijn niet automatisch bugs. Het is normaal wanneer verschillende teams een complexe standaard onafhankelijk implementeren. Gereguleerde sectoren vragen daarom vaak een tweede bevestiging.

Referentie-engine plus tweede mening

veraPDF is de referentie-implementatie van de PDF Association. Als veraPDF “Pass” zegt, is dat het sterkste single-engine signaal voor PDF/A.

Maar het sterkste enkele signaal is nog geen auditbewijs. Banken, medische archieven, overheden en langetermijnarchieven willen vaak een tweede engine omdat:

De ontvanger intern een andere validator kan gebruiken.
Een bug in een engine niet zichtbaar wordt door dezelfde engine twee keer te draaien.
Twee onafhankelijke bevestigingen een bekend compliance-principe zijn.

gPdf combineert veraPDF met onze eigen engine in Rust + WebAssembly. Dat is een onafhankelijke implementatie van dezelfde specificatie. Als beide engines slagen, is de conclusie veel sterker; als ze verschillen, heb je een duidelijke plek om te onderzoeken.

Twee rapporten via een URL

Dit is gratis beschikbaar op gpdf.com/validator/. Geen login: upload het bestand, veraPDF en de gPdf edge engine draaien parallel en je krijgt twee rapporten naast elkaar.

Typische workflows:

Voor verzending van PDF/A: uploaden, twee “Pass” zien, JSON-rapporten bewaren als QA evidence.
Een engine slaagt, een faalt: rapporten vergelijken; vaak zit het in XMP, een /AF-referentie of attachment metadata.
Beide falen: de generatie aan de bron corrigeren.
Archive batch audit: samples valideren en resultaten aan het auditdossier toevoegen.

Het bestand wordt niet opgeslagen. Het draait in-memory op Cloudflare Workers en wordt na het rapport weggegooid.

Hetzelfde patroon voor e-invoicing

Bij Factur-X / ZUGFeRD moet je naast PDF/A-3 ook de embedded EN 16931 CII XML valideren. De gPdf validator gebruikt Mustang voor dat XML-deel en toont het resultaat naast het PDF/A-rapport.

Dit gaat niet om wantrouwen tegenover een tool. Het gaat om sterker bewijs uit onafhankelijke implementaties.

TL;DR

Een enkele “Pass” is geel licht. Twee onafhankelijke “Pass” zijn veel sterker. Upload je bestand naar validator, download beide rapporten en voeg ze toe aan QA of audit. Als gPdf de PDF genereerde, is de validator het publieke bewijs van de complianceclaim.