PDF/A ist die Archivvariante von PDF: die Zusage, dass ein Dokument im Jahr 2050 genauso gerendert wird wie 2026. Es gibt vier große Profile (PDF/A-1, 2, 3, 4), jeweils mit Unterstufen der Konformität. PDF/A-3 ist das Profil, das europäische E-Rechnungen praktisch möglich macht, und das einzige breit genutzte PDF/A-Profil, das beliebige Dateianhänge im Archiv-Wrapper erlaubt.

Wenn Sie Rechnungen, regulatorische Einreichungen oder Workflows mit “PDF + structured data” bauen, werden Sie PDF/A-3 begegnen. Hier ist die technische Kurzfassung: was es ist, wie es sich unterscheidet und wie Sie die echte Konformität prüfen.

Die PDF/A-Familie auf einen Blick

Profil	ISO part	Jahr	Prägendes Merkmal
PDF/A-1	19005-1	2005	Erstes Archivprofil. Keine Transparenz, kein JavaScript, Fonts eingebettet.
PDF/A-2	19005-2	2011	Ergänzt JPEG2000, Transparenz und Ebenen. Bessere Drucktreue.
PDF/A-3	19005-3	2012	Ergänzt embedded file attachments. Wrapper für Factur-X / ZUGFeRD.
PDF/A-4	19005-4	2020	Moderne Revision; saubereres Konformitätsmodell, kein `b` vs `a` split.

Die Unterstufen:

b (basic): visuelle Wiedergabe bleibt erhalten, ohne semantische Garantien.
a (accessible): Struktur-Tags und Unicode mapping für Screenreader.
u (Unicode): Unicode mapping ohne vollständige Struktur.
e / f (nur PDF/A-4): Engineering-3D-Inhalte und vollständige Formulare.

“PDF/A-3b” bedeutet also: Archivprofil 3 mit erlaubten Anhängen, basic level ohne Pflicht zu Accessibility-Tags. Das ist die übliche Variante für Rechnungen.

Was PDF/A-3 besonders macht

PDF/A-1 und PDF/A-2 verbieten beliebige eingebettete Dateien. Die Begründung: Ein Archiv-PDF soll selbstständig sein; ein angehängtes data.xlsx könnte unabhängig vom PDF veralten und die Archivgarantie brechen.

PDF/A-3 lockert diese Regel unter einer engen Bedingung: Jede eingebettete Datei muss ein AFRelationship deklarieren, das die Beziehung zum sichtbaren PDF-Inhalt beschreibt. Gültige Werte sind Source, Data, Alternative, Supplement, Unspecified. Das PDF muss den Anhang außerdem im /AF array aufführen und XMP metadata zur Datei ausgeben.

Anders gesagt: PDF/A-3 erlaubt Anhänge, verlangt aber eine klare Deklaration, was sie sind und wie sie zum sichtbaren Dokument gehören. Genau das macht E-Rechnungen möglich: Die menschenlesbare Rechnung steckt im PDF, das maschinenlesbare EN 16931 CII XML im Anhang, und AFRelationship="Alternative" sagt, dass beide dieselbe Rechnung darstellen.

Wo PDF/A-3 in Produktion steht

Factur-X (Frankreich, B2B ab 2026 schrittweise verpflichtend): PDF/A-3 + CII XML, mit XMP namespace urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#.
ZUGFeRD 2.x (Deutschland, Empfang seit 2025 verpflichtend): PDF/A-3 + CII XML, mit XMP namespace urn:zugferd:pdfa:CrossIndustryDocument:invoice:2p0#.
Engineering-CAD-Archivierung: PDF/A-3 mit angehängter nativer CAD-Datei. PDF ist die Darstellung, CAD die Quelle.
Regulatorische Einreichungen: PDF/A-3 mit XML payloads, etwa FDA submissions oder ESEF financial reports börsennotierter EU-Unternehmen.

In diesen Fällen ist der Wrapper nicht nur ein Container. Er ist ein Vertrag: Dieses PDF und diese angehängte Datei sind dasselbe Dokument, und beide müssen validieren.

So prüfen Sie PDF/A-3-Konformität

Der offizielle Checker ist veraPDF (verapdf.org), gepflegt von der PDF Association. Er implementiert das ISO 19005-3-Regelwerk. Wenn veraPDF “Pass — PDF/A-3b” meldet, ist das das stärkste Signal, das ein einzelner Motor geben kann.

Ein single-engine “Pass” ist aber kein Audit-Standard (Why two PDF/A validators are better than one erklärt den Grund). Das belastbare Muster ist, zwei unabhängige Engines laufen zu lassen und die Datei nur bei zwei Passes als konform zu behandeln.

Für E-Rechnungen brauchen Sie zusätzlich Mustang (mustangproject.org), den De-facto-Checker für Factur-X / ZUGFeRD. Mustang validiert das eingebettete CII XML gegen EN 16931 Schematron. PDF/A-3-Konformität allein reicht nicht; das angehängte XML muss ebenfalls gültiges EN 16931 sein, sonst weist das AP-System des Empfängers die Rechnung ab.

Viele Teams installieren Java, richten die veraPDF CLI ein, installieren Mustang und schreiben dann Shell-Skripte für die Ausgaben. Das funktioniert, ist aber Reibung.

validator führt alle drei im Browser aus:

veraPDF: offizielle Referenz für PDF/A-3-Konformität.
gPdf Rust+WASM edge engine: unabhängige Implementierung als second opinion.
Mustang: EN 16931 CII XML Schematron für eingebettete E-Rechnungsdaten.

Datei ablegen, drei Engines laufen parallel, Reports erscheinen nebeneinander. JSON kann als QA evidence heruntergeladen werden. Kein Login, keine quota.

Worauf Sie im Report achten sollten

Fehler häufen sich meist hier:

Embedded file metadata missing: /AF array fehlt, oder der Anhang ist nicht darin gelistet.
AFRelationship missing or wrong: Für E-Rechnung muss es Alternative sein; viele PDF libraries setzen Source oder Data als default.
XMP namespace missing or wrong: Factur-X und ZUGFeRD haben feste namespace URIs; ein Zeichenfehler reicht.
Fonts not subsetted or not embedded: PDF/A verlangt, dass alle verwendeten glyphs mit dem Font eingebettet sind.
Output intent missing: PDF/A verlangt eine Farbintention (sRGB oder anderes ICC profile), auch bei reinem Schwarz-Weiß-Text.
Document metadata incomplete: /Title, /Producer, /CreationDate müssen im information dictionary stehen.

Der Report verweist typischerweise auf den passenden Spezifikationsabschnitt. Beheben Sie die Ursache an der Quelle; wenn Sie mit gPdf generieren, übernimmt die API diese Details, und der validator ist Ihr öffentlicher Beleg.

TL;DR

PDF/A-3 = PDF/A-2 + die rechtssichere Möglichkeit, beliebige Dateien einzubetten. Diese Fähigkeit macht EU-E-Rechnungen praktikabel: menschenlesbare Rechnung + strukturiertes EN 16931 CII XML in einem Archiv-Wrapper. Sowohl der PDF/A-3 wrapper als auch das attached XML müssen bestehen.

Generieren mit POST /api/v1/e-invoice/render. Prüfen unter validator. Drei Engines (veraPDF + gPdf edge + Mustang), ein Upload, kostenlos.