PDF/A-3: Warum ZUGFeRD ausgerechnet dieses Format braucht

Ein Archivformat als Träger

PDF/A ist die Familie der PDF-Varianten, die für Langzeitarchivierung entwickelt wurden. Der Grundgedanke: Eine Datei soll in zwanzig Jahren noch genauso aussehen wie heute — auch wenn es die Schriftart, das Farbprofil oder das Programm, das sie erzeugt hat, längst nicht mehr gibt.

Daraus folgen die typischen Anforderungen: Schriften müssen eingebettet sein. Farbprofile müssen mitgeliefert werden. Verweise auf externe Inhalte sind untersagt. Alles, was die Datei zur Darstellung braucht, muss in ihr liegen.

Warum es A-3 sein muss

Innerhalb der Familie unterscheiden sich die Stufen darin, was eingebettet werden darf:

PDF/A-1 verbietet Anhänge vollständig — sie wären ein Verweis auf etwas, das die Darstellung nicht garantieren kann. PDF/A-2 lockerte das, aber nur für andere PDF/A-Dateien.

Erst PDF/A-3 erlaubt es, eine beliebige Datei einzubetten und sie als zugehörig zu kennzeichnen. Genau das braucht ein Hybridformat: Das XML ist kein PDF, und es soll trotzdem Teil des Archivobjekts sein.

💡 Diese Reihenfolge ist wichtig für das Verständnis: PDF/A-3 wurde nicht für E-Rechnungen erfunden. ZUGFeRD hat eine bestehende Möglichkeit genutzt — und ist heute ihr bekanntester Anwendungsfall.

Wie die Einbettung aussieht

Das eingebettete XML ist kein loser Anhang, sondern trägt eine Beziehungsangabe, die seine Rolle beschreibt:

1rechnung.pdf  (PDF/A-3b)
2└── Anhang
3    ├── Dateiname     (in der Spezifikation festgelegt)
4    ├── Relationship  Alternative
5    └── MIME-Typ      text/xml

Die Angabe Alternative sagt: Diese Datei ist eine andere Darstellung desselben Inhalts — nicht eine Beilage, nicht ein Zusatzdokument. Genau das trifft auf die XML-Rechnung zu.

🔴 Der Dateiname ist dabei keine Nebensache. Er ist in der Spezifikation festgelegt, und ein Prüfprogramm sucht genau diesen Namen. Steht dort ein anderer, meldet die Prüfung „kein XML gefunden" — obwohl die Datei vorhanden ist. Diese Fehlermeldung zeigt in die falsche Richtung und kostet regelmäßig Stunden.

Woran die Prüfung scheitert

Bei einer ZUGFeRD-Datei prüft ein Validator zwei Dinge unabhängig voneinander: die Hülle (ist es gültiges PDF/A-3?) und den Inhalt (erfüllt das XML sein Regelwerk?). Beide können getrennt scheitern.

Die häufigsten Gründe auf der Hüllenseite haben mit Rechnungen nichts zu tun:

• Schriften nicht eingebettet. Der Klassiker. Ein PDF, das eine Systemschrift referenziert, ist nicht archivtauglich.
• Transparenz. In PDF/A-1 verboten, in A-2 und A-3 erlaubt — Bibliotheken, die intern noch nach A-1 arbeiten, stolpern hier.
• Fehlendes Farbprofil. Ohne Profil ist nicht definiert, wie eine Farbe aussehen soll.
• Verschlüsselung. Ein passwortgeschütztes PDF kann nicht archivkonform sein.

Diese Fehler entstehen in der PDF-Erzeugung, nicht in der Rechnungslogik. Wer sie im Rechnungsdatenmodell sucht, sucht am falschen Ort.

Konformitätsstufen a und b

Sie treffen auf Angaben wie PDF/A-3b oder PDF/A-3a:

• b (basic) — die verlässliche visuelle Wiedergabe ist gesichert.
• a (accessible) — zusätzlich ist die logische Dokumentstruktur maschinenlesbar hinterlegt, für Barrierefreiheit.

Für ZUGFeRD genügt üblicherweise b. Stufe a ist deutlich aufwendiger zu erzeugen und wird durch die Rechnungsanforderungen nicht verlangt.

Und die Aufbewahrung

Weil PDF/A-3 ein Archivformat ist, liegt der Gedanke nahe, damit sei die Aufbewahrungsfrage beantwortet. Sie ist es nicht ganz.

Das Format sichert die Lesbarkeit über die Zeit. Die Unveränderbarkeit und die Nachvollziehbarkeit jeder Bearbeitung sichert es nicht — das ist Aufgabe des Systems, in dem die Datei liegt.

🔵 Und: Aufzubewahren ist die ganze Datei, nicht das extrahierte XML und nicht ein Ausdruck. Das Original ist die Kombination aus sichtbarem Beleg und eingebetteten Daten.