Ein PDF erfüllt PDF/A-3 oder es erfüllt es nicht. Warum sollte man dieselbe Datei dann mit zwei Validatoren prüfen?

Weil die Realität komplizierter ist: Die PDF/A-Spezifikation ist groß genug, dass zwei korrekte Implementierungen an Randfällen unterschiedlich urteilen können. In einem auditfähigen Prozess ist ein einzelnes “Pass” eher gelb als grün.

PDF/A ist kein einzelner Algorithmus

PDF/A ist über mehrere Teile von ISO 19005 verteilt: PDF/A-1, PDF/A-2, PDF/A-3 und PDF/A-4, jeweils mit Stufen wie b, a, u, e und f. Darunter liegt zusätzlich die PDF-Basisspezifikation ISO 32000. Zusammen sind das tausende Seiten normativer Text.

Typische Streitpunkte:

Transparenz in PDF/A-2/3: erlaubt unter bestimmten Bedingungen, deren Grenzen Validatoren unterschiedlich prüfen.
ICC-Farbprofile: Pflicht, Empfehlung oder unzureichend? Die Strenge variiert.
Eingebettete Dateien in PDF/A-3: AFRelationship, /AF-Referenzen und XMP müssen sauber zusammenpassen.
Font-Subsetting: CID-Fonts und partielle Subsets erzeugen klassische Grenzfälle.

Das sind nicht automatisch Bugs. Es ist die natürliche Folge eines komplexen Standards, der unabhängig implementiert wird. Regulierte Branchen verlangen deshalb oft eine zweite Bestätigung.

Referenz-Engine plus unabhängige Zweitmeinung

veraPDF ist die Referenzimplementierung der PDF Association. Wenn veraPDF “Pass” meldet, ist das das stärkste Einzelsignal für PDF/A.

Aber das stärkste Einzelsignal ist noch kein Audit-Nachweis. Banken, Gesundheitsarchive, Behörden und Langzeitarchive wollen häufig einen zweiten Validator, weil:

Der Empfänger intern ein anderes Prüfwerkzeug nutzen kann.
Ein Fehler in einer Engine nicht sichtbar wird, wenn man dieselbe Engine zweimal ausführt.
Zwei unabhängige Bestätigungen in Compliance-Prozessen üblich sind.

gPdf kombiniert veraPDF mit einer eigenen Engine in Rust + WebAssembly. Sie implementiert dieselbe Spezifikation unabhängig. Bestehen beide Engines, ist die Aussage deutlich stärker; widersprechen sie sich, gibt es einen klaren Ansatzpunkt für die Analyse.

Zwei Reports unter einer URL

Das ist kostenlos unter gpdf.com/validator/ verfügbar. Ohne Login: Datei hochladen, veraPDF und die gPdf Edge Engine laufen parallel, zwei Reports erscheinen nebeneinander.

Typische Workflows:

PDF/A vor Auslieferung prüfen: hochladen, zwei “Pass” sehen, JSON-Reports als QA-Nachweis archivieren.
Eine Engine besteht, eine fällt durch: Reports vergleichen; oft geht es um XMP, /AF oder Attachment-Metadaten.
Beide fallen durch: die Generierung an der Quelle korrigieren.
Archiv-Batch auditieren: Stichproben prüfen und Reports an die Arbeitspapiere hängen.

Die Datei wird nicht gespeichert. Sie wird in Cloudflare Workers im Speicher verarbeitet und nach dem Report verworfen.

Dasselbe Muster gilt für E-Rechnungen

Bei Factur-X / ZUGFeRD reicht PDF/A-3 allein nicht. Auch das eingebettete EN 16931 CII XML muss validiert werden. Der gPdf Validator nutzt dafür Mustang und zeigt das Ergebnis neben dem PDF/A-Report.

Es geht nicht darum, einem Tool zu misstrauen. Es geht darum, belastbare Evidenz aus unabhängigen Implementierungen zu erzeugen.

TL;DR

Ein einzelnes “Pass” ist gelb. Zwei unabhängige “Pass” sind ein deutlich stärkerer Nachweis. Datei in validator hochladen, beide Reports sichern und als QA- oder Audit-Beleg verwenden. Für mit gPdf erzeugte PDFs ist der Validator der öffentliche Beleg für den Compliance-Anspruch.