Ein PDF entspricht PDF/A-3, oder es entspricht ihm nicht. Warum sollte also jemand zwei Validatoren auf dieselbe Datei ansetzen?

Kurzantwort: Weil die Spezifikation groß genug ist, dass zwei korrekte Implementierungen an den Rändern uneinig sein können, und ein auditfähiger Workflow ein einzelnes “Pass” nicht als grüne Ampel, sondern als gelbe Ampel behandelt. Hier ist die längere Version.

PDF/A ist ein Stapel ausgehandelter Regeln, kein einzelner Algorithmus

PDF/A ist über mehrere ISO-19005-Teile definiert (PDF/A-1, PDF/A-2, PDF/A-3, PDF/A-4), jeweils mit Unterkonformitätsstufen (b, a, u, e, f). Jede davon baut auf der zugrunde liegenden PDF-Spezifikation (ISO 32000) auf. Zusammen ist die Oberfläche mehrere tausend Seiten normativer Text groß.

Einige Beispiele, bei denen konforme Implementierungen historisch auseinanderlagen:

Transparenz in PDF/A-2/3: unter bestimmten Bedingungen erlaubt; die Bedingungen sind prozedural formuliert und werden von Validatoren unterschiedlich geprüft.
Eingebettete Farbprofile: Wann ist ein ICC-Profil “erforderlich” und wann nur “empfohlen”? Unterschiedliche Validatoren haben dieselbe Datei auf dieser Achse als “Pass” und “Fail” bewertet.
Metadaten eingebetteter Dateien in PDF/A-3: AFRelationship, /AF-Referenzen und eingebettetes XMP sind klar spezifiziert, aber die Durchsetzungsstrenge variiert.
Font-Subsetting: PDF/A verlangt, dass alle Fonts mit ihrer tatsächlichen Kodierung eingebettet werden. Randfälle rund um CID-keyed Fonts mit partiellen Subsets haben zu Validator-Unterschieden geführt.

Das sind keine Bugs. Es ist die natürliche Folge einer komplexen Spezifikation, die von unabhängigen Teams aus normativem Text implementiert wird. Die konservative Position - und die Position vieler regulierter Branchen - verlangt mehrere unabhängige Bestätigungen.

Die Referenz-Engine plus die zweite Meinung

veraPDF ist die Referenzimplementierung der PDF Association, also der Standardisierungsorganisation, die PDF/A veröffentlicht. veraPDF ist Open Source, wird von Industriearbeitsgruppen geprüft und sein Regelwerk ist die kanonische Interpretation des ISO-19005-Texts. Wenn veraPDF “Pass” sagt, ist das das stärkste Signal, das eine einzelne Engine liefern kann.

Aber “stärkstes Einzelsignal” ist nicht dasselbe wie “auditfähige Evidenz”. Auditoren in regulierten Institutionen - Banken, Gesundheitsdatenarchive, Behördenarchive - verlangen häufig eine zweite unabhängige Bestätigung, weil:

die veraPDF-Interpretation einer Regel von einem anderen Validator abweichen kann, den der Empfänger intern nutzt, was später zu einer Zurückweisung führt;
ein Bug in einer einzelnen Engine, selbst in der Referenz, nicht erkennbar wird, wenn dieselbe Engine zweimal läuft;
das Beschaffungsprinzip “zwei unabhängige Bestätigungen” in Compliance-Domänen breit angewandt wird; PDF/A erbt diese Erwartung aus seinen Archivierungs-Use-Cases.

Welche zweite Engine sinnvoll ist, hängt von der Verfügbarkeit ab:

Adobe Acrobat Preflight ist kostenpflichtig und closed-source: als Bestätigungsengine brauchbar, aber mit begrenzter Nachprüfbarkeit durch Dritte.
callas pdfaPilot ist kostenpflichtig und die De-facto-Enterprise-Wahl, begrenzt aber ebenfalls unabhängige Re-Verification.
Eine zweite Open-Source-Engine: Es gibt einige, die meist weniger vollständig sind als veraPDF.

Was wir bei gPdf getan haben: Wir haben unsere eigene Engine in Rust + WebAssembly als bewusste unabhängige Neuimplementierung gebaut. Dieselbe Spezifikation, dieselben Regeln, von einem anderen Team von Grund auf geschrieben. Wenn beide Engines dieselbe Datei bestehen lassen, ist die Schlussfolgerung deutlich stärker als jede für sich. Wenn sie sich widersprechen, haben Sie einen klaren Bug zu untersuchen: in einer Engine oder in der Datei.

Der Validator, der beide auf eine URL legt

Wir hosten beides unter gpdf.com/validator/: kostenlos, ohne Login. Die Datei läuft parallel durch veraPDF UND unsere Edge Engine, und beide Reports erscheinen nebeneinander. Die Use Cases:

Sie erzeugen ein PDF/A und möchten es ausliefern: in den Validator ziehen, beide bestehen, JSON-Reports als QA-Evidenz anhängen. Fertig.
Eine Engine fällt durch, die andere besteht: Sie haben einen präzisen Bug. Reports vergleichen, das betroffene Feld finden. Oft ist es etwas Feines wie ein verschobener XMP-Zeitstempel oder eine fehlende /AF-Referenz in PDF/A-3.
Beide fallen durch: Die Datei ist wirklich kaputt; an der Quelle reparieren.
Audit eines eingehenden Archiv-Batches: zufällig ausgewählte PDFs hineinziehen, Report-URLs protokollieren, dem Audit-Arbeitspapier anhängen. “Wir haben mit veraPDF und einer unabhängigen Engine geprüft” ist eine stärkere Aussage als “wir haben den Checker unseres Anbieters ausgeführt.”

Die hochgeladene Datei verlässt den Request nicht: Die Engines laufen im Speicher auf Cloudflare Workers, und die Datei wird nach dem Rendern des Reports verworfen. Kein Login, keine Persistenz, keine Quote.

Dasselbe Muster, verallgemeinert

Es geht nicht nur um PDF/A. Das Muster “zwei unabhängige Bestätigungen” gilt auch für:

Factur-X / ZUGFeRD E-Rechnungen: gpdf.com/validator/ führt Mustang (mustangproject.org) für das eingebettete EN 16931 CII XML aus, zusätzlich zur PDF/A-Prüfung oben. (ZUGFeRD mit Mustang validieren: was besteht, was durchfällt beschreibt diesen Workflow.)
TLS-Zertifikate: Moderne CA-Logs werden von mehreren Monitoren gegengeprüft.
Build-Reproduzierbarkeit: Zwei unabhängige Rebuilds aus derselben Quelle sollten byte-identische Outputs erzeugen.

Die Compliance-Welt arbeitet seit Jahrzehnten so. PDF/A holt nur auf.

TL;DR

Ein einzelnes “Pass” ist gelb. Zwei Engine-“Pass” sind grün. Beide Engines sind kostenlos im Validator verfügbar: Datei ablegen, zwei Reports erhalten, an Ihre QA-Evidenz anhängen. Wenn gPdf die Datei erzeugt hat, ist der Validator der öffentliche Beleg, dass die API ihren Compliance-Anspruch erfüllt.

Wenn Sie auf der gPdf API bauen, zeigt die E-invoice API reference (§5), wie Sie Factur-X / ZUGFeRD PDF/A-3 direkt ausgeben. Der Validator bestätigt es danach extern. Zwei Engines, ein Upload: Das ist das auditfähige Muster.