Was ist PDF/A-3 und warum ist es für die E-Rechnung relevant?

Wer sich in den letzten zwei Jahren mit europäischer E-Rechnung beschäftigt hat, ist dem Begriff PDF/A-3 zweifellos begegnet, als wäre er allgemein bekannt. Die meisten Artikel setzen voraus, dass die Leser den Unterschied zwischen PDF, PDF/A und PDF/A-3 kennen, und fahren dann fort. Diese Unterschiede sind nicht akademisch. Sie entscheiden darüber, ob eine heute versendete Rechnung 2036 noch geöffnet, geprüft und rechtlich gültig sein wird.

Hier ist die Erklärung, die wir uns selbst gewünscht hätten.

PDF, PDF/A, PDF/A-3: drei verschiedene Dinge

Ein reguläres PDF ist ein Präsentationsformat. Es kann alles enthalten, was ein Designer möchte: externe Schriftartreferenzen, JavaScript, eingebettetes Video, Links zu externen Ressourcen. Diese Flexibilität ist großartig für Marketingbroschüren und katastrophal für Archive. Eine PDF von 2005 kann im Viewer von 2025 bereits anders dargestellt werden, weil eine Schriftart ersetzt wurde, eine externe Ressource nicht mehr verfügbar ist oder eine Anbieter-Erweiterung abgekündigt wurde.

PDF/A (ISO 19005) ist eine strenge Untermenge von PDF, die für identisches Rendering für alle Zeit ausgelegt ist. Sie verbietet die dynamischen Funktionen. Jede Schriftart muss eingebettet sein. Jedes Farbprofil muss eigenständig enthalten sein. Kein JavaScript, kein externer Inhalt, keine Verschlüsselung. Das Ergebnis ist eine Datei, die garantiert noch in Jahrzehnten geöffnet werden kann und visuell identisch dargestellt wird.

PDF/A-3 ist die dritte Revision dieses Standards, veröffentlicht 2012. Sie änderte genau eine Sache: Sie erlaubt das Einbetten beliebiger Anhänge in die PDF. Frühere Versionen (PDF/A-1, PDF/A-2) erlaubten nur Anhänge, die selbst PDF/A-konform waren. PDF/A-3 hob diese Einschränkung auf. Nun kann eine XML-Datei, eine CSV, ein JSON-Dokument oder beliebige andere Inhalte als strukturierter Anhang eingebettet werden.

Diese einzige Änderung hat moderne E-Rechnung erst möglich gemacht.

Warum E-Rechnung genau das benötigte

Eine konforme europäische E-Rechnung muss zwei Dinge gleichzeitig sein:

1. Maschinenlesbar. Das Buchungssystem des Käufers muss Positionen, Steuersätze und Zahlungsbedingungen ohne menschlichen Eingriff verarbeiten können.
2. Menschenlesbar, über Jahre. Das Steuerrecht in den meisten EU-Ländern verlangt, dass die Rechnung in einer Form archiviert wird, die ein menschlicher Prüfer öffnen und lesen kann, für Zeiträume zwischen 7 und 10 Jahren.

Eine reine UBL-XML-Datei erfüllt die erste Anforderung, scheitert aber an der zweiten. Eine reine PDF erfüllt die zweite, aber nicht die erste. Eine PDF/A-3 mit eingebettetem UBL erfüllt beide, in einem einzigen manipulationssicheren Container, und die visuelle Schicht ist bit-identisch mit der strukturierten Schicht.

Das ist die Architektur hinter Factur-X (dem französisch-deutschen Hybridrechnungsstandard) und ZUGFeRD (seinem deutschen Vorläufer). Beide sind PDF/A-3 mit einem spezifischen XML-Anhang an einer bestimmten Stelle mit einem bestimmten Dateinamen. Hinter den Markennamen verbirgt sich im Wesentlichen: “PDF/A-3 plus eine Vereinbarung darüber, welches XML darin enthalten ist.”

Was PDF/A-3 nicht leistet

PDF/A-3 ist ein Archivierungsformat. Es ist kein Konformitätszertifikat und keine Signatur. Drei Dinge leistet es ausdrücklich nicht:

• Es validiert das eingebettete XML nicht. Sie können fehlerhaftes UBL in eine PDF/A-3 einbetten, und die Datei besteht trotzdem die PDF/A-3-Validierung. Das Format garantiert nur den Container, nicht den Inhalt.
• Es beweist nicht, wann die Datei erstellt wurde. Eine PDF/A-3-Datei kann erneut gespeichert, neu zeitgestempelt und wieder versendet werden, ohne Spuren zu hinterlassen. Wenn Sie nachweisen müssen, dass “diese Rechnung an diesem Datum existierte”, benötigen Sie dafür zusätzlich einen RFC-3161-Zeitstempel.
• Es garantiert keine Zustellung. Konformität mit dem Format und Konformität mit einem nationalen Mandat (Peppol, KSeF, Chorus Pro) sind verschiedene Probleme. PDF/A-3 ist notwendig, aber nicht hinreichend.

Deshalb erzeugt die SealDoc-Pipeline eine PDF/A-3 plus einen RFC-3161-Zeitstempel plus ein Evidence Pack mit Manifest-Hashes. Jede Schicht beantwortet eine andere Frage, und eine echte Prüfung wird alle drei verlangen.

Häufige Fehler in Pipelines bei PDF/A-3

Immer wieder sehen wir dieselben fünf Fehler in Kundenpipelines:

1. Unvollständig konvertierte PDFs. Eine Bibliothek behauptet, “PDF/A-3 zu erzeugen”, lässt aber die Einbettung von Systemschriftarten aus, die auf dem Rechner des Prüfers dann anders aufgelöst werden.
2. Falsche Anhangsbeziehung. PDF/A-3 unterscheidet zwischen Source, Data, Alternative, Supplement und Unspecified. Factur-X erfordert Alternative. Viele Einbetter verwenden standardmäßig Unspecified, und die Datei scheitert bei der strengen Validierung.
3. Fehlende XMP-Metadaten. PDF/A erfordert selbstbeschreibende Metadaten in XMP. Eine Datei ohne die erforderlichen Schlüssel pdfaid:part und pdfaid:conformance ist technisch nicht PDF/A-3, unabhängig von der Struktur.
4. Farbprofil-Abweichungen. Eine PDF/A-3 muss jeden verwendeten Farbraum deklarieren. Pipelines, die beliebige RGB-Bilder ohne eingebettetes Profil durchlassen, erzeugen stillschweigend nicht-konforme Dateien.
5. Neurendering einer bestehenden PDF. Manche Pipelines rastern die Eingabe-PDF, bevor sie XML einbetten. Das funktioniert optisch, zerstört aber die durchsuchbare Textschicht und verletzt die Barrierefreiheit.

Sie können all das mit unserem öffentlichen Validator unter /check prüfen. Laden Sie eine Datei hoch, erhalten Sie in Sekunden ein Urteil, keine Anmeldung erforderlich. Schlägt eine Datei fehl, zeigt der Bericht genau, welche Klausel welcher Spezifikation verletzt wurde.

Wann PDF/A-3 die richtige Wahl ist (und wann nicht)

PDF/A-3 ist die richtige Wahl, wenn Sie eine menschenlesbare Kopie eines strukturierten Dokuments für Jahre aufbewahren müssen und beide Schichten in einer Datei haben wollen. Das umfasst E-Rechnungen, E-Belege, strukturierte Verträge und zunehmend E-Tickets und Zolldokumente.

Die falsche Wahl ist es für kurzlebige Dokumente (ein Lieferschein, der in einer Woche hinfällig wird), für Dokumente, bei denen die strukturierte Nutzlast das Einzige ist, was zählt (reines EDI), oder wo die menschenlesbare Schicht rein dekorativ ist und nie geprüft wird.

Für alle anderen im EU-B2B-Bereich im Jahr 2026 ist PDF/A-3 das Format. Die oben beschriebenen technischen Details erklären, warum es funktioniert, und warum eine fehlerhafte Implementierung stillschweigend Dateien erzeugt, die die interne QA bestehen und beim Prüfer drei Jahre später scheitern.