PDF/A-3 und ZUGFeRD: warum eine normale PDF nicht genügt

Eine ZUGFeRD-Rechnung ist eine PDF — aber nicht jede PDF kann eine ZUGFeRD-Rechnung werden. Der Standard verlangt eine PDF/A-3, und daran scheitern in der Praxis mehr Dateien als an den Rechnungsdaten selbst. Dieser Artikel erklärt, was PDF/A ist, warum ZUGFeRD ausgerechnet die Variante 3 braucht, woran gewöhnliche PDFs scheitern und wie Sie prüfen, ob Ihre Datei konform ist.

Was PDF/A ist

PDF ist ein flexibles Format: Eine Datei darf auf Schriften verweisen, die auf dem Rechner des Lesers installiert sind, Inhalte nachladen, Skripte enthalten, sich je nach Anzeigeprogramm anders darstellen. Für ein Werbeprospekt ist das gleichgültig. Für einen Beleg, der acht Jahre aufbewahrt und in zehn Jahren noch lesbar sein muss, ist es ein Problem.

PDF/A (ISO 19005) beseitigt genau diese Flexibilität. Die Kernregeln:

• Alle Schriften sind eingebettet. Die Datei bringt mit, was sie zur Darstellung braucht.
• Farben sind eindeutig definiert, über ein eingebettetes Ausgabeprofil (Output Intent).
• Keine externen Verweise, keine nachgeladenen Inhalte, kein JavaScript, keine Verschlüsselung.
• XMP-Metadaten beschreiben die Datei selbst und deklarieren, welcher PDF/A-Variante sie folgt.

Das Ergebnis: eine Datei, die in zehn Jahren genauso aussieht wie heute — unabhängig davon, welche Schriften auf dem Rechner installiert sind.

Warum ZUGFeRD gerade PDF/A-3 braucht

Von PDF/A gibt es mehrere Generationen, und sie unterscheiden sich in einem für ZUGFeRD entscheidenden Punkt.

ZUGFeRD ist ein hybrides Format: eine lesbare Rechnung für Menschen plus dieselben Daten strukturiert für Maschinen. Der strukturierte Teil ist eine XML-Datei — und die darf nur in einer PDF/A-3 mitreisen. Was ZUGFeRD im Ganzen ausmacht, erklärt der Leitfaden ZUGFeRD.

Der Anhang ist dabei nicht einfach angeheftet. Er muss:

• den festgelegten Dateinamen tragen: factur-x.xml bei ZUGFeRD 2.x und Factur-X (ältere Versionen: ZUGFeRD-invoice.xml),
• über AFRelationship als zugehörige Datei markiert sein — üblicherweise mit dem Wert Alternative, weil das XML eine alternative Darstellung derselben Rechnung ist,
• in den XMP-Metadaten deklariert sein, zusammen mit ZUGFeRD-Version und Profil.

Fehlt eine dieser drei Angaben, findet ein Empfängersystem das XML nicht — und behandelt die Datei als gewöhnliche PDF, also als sonstige Rechnung.

Woran gewöhnliche PDFs scheitern

Die häufigsten Ursachen, in der Reihenfolge ihres Auftretens:

Schriften nicht eingebettet. Der Klassiker bei PDFs aus Textverarbeitungen mit Systemschriften. Bei der Prüfung fällt die Datei sofort durch.

Kein Ausgabeprofil. Ohne eingebettetes Farbprofil ist unbestimmt, wie die Farben zu interpretieren sind. PDF/A verlangt eines — üblich ist sRGB.

Fehlende oder falsche XMP-Metadaten. Die Datei behauptet nicht, PDF/A zu sein, oder deklariert die falsche Variante. Ein Prüfer entscheidet nach dem, was die Datei über sich sagt.

Transparenz und moderne PDF-Funktionen. PDF/A-1 verbietet Transparenz vollständig; bei PDF/A-2 und -3 ist sie erlaubt, aber an Bedingungen geknüpft. Grafiken aus Layoutprogrammen stolpern hier gelegentlich.

Verschlüsselung oder Passwortschutz. In PDF/A unzulässig — auch ein bloßer Druckschutz.

Angehängtes XML ohne PDF/A-3-Basis. Jemand nimmt eine gewöhnliche PDF und hängt ein XML an. Technisch geht das; als ZUGFeRD gilt es nicht.

Wie Sie die Konformität prüfen

veraPDF (verapdf.org) ist der Open-Source-Standardprüfer für PDF/A. Er sagt Ihnen genau, welche Anforderung verletzt ist — inklusive Fundstelle in der Norm. Für die Frage „Warum ist meine Datei keine PDF/A-3?" das beste Werkzeug.

Mustangproject prüft die PDF-Ebene mit (intern über veraPDF) und zusätzlich das XML gegen Schema und Geschäftsregeln:

java -jar Mustang-CLI-2.24.0.jar --no-notices --action validate --source rechnung.pdf

Im Bericht ist der Block <pdf> die PDF/A-Ebene. Steht dort status="valid", ist die Hülle in Ordnung. Wie der Bericht im Ganzen zu lesen ist, steht im Artikel ZUGFeRD-Validator.

Adobe Acrobat zeigt in den Dokumenteigenschaften an, ob eine Datei als PDF/A deklariert ist, und kann eine Preflight-Prüfung durchführen. Für einen schnellen Blick genügt das; die Deklaration allein ist aber kein Beweis für Konformität.

Kann man eine bestehende PDF nachträglich umwandeln?

Technisch gibt es Werkzeuge, die eine PDF in Richtung PDF/A konvertieren — Acrobat, Ghostscript und einige Bibliotheken können das. Die Konvertierung bettet fehlende Schriften ein und ergänzt ein Ausgabeprofil. Was sie nicht kann: fehlende Rechnungsdaten erfinden.

Deshalb ist der Weg „PDF nehmen, konvertieren, XML anhängen" in der Praxis unbrauchbar. Die Rechnungsdaten müssten aus der PDF herausgelesen werden — das ist Texterkennung mit Ratespiel, und ein falsch erkannter Betrag macht die Rechnung fehlerhaft, ohne dass es jemandem auffällt. Warum das grundsätzlich kein guter Weg ist, steht ausführlich im Artikel PDF in E-Rechnung umwandeln.

Der richtige Weg ist umgekehrt: Das Rechnungsprogramm hält die Daten strukturiert vor und erzeugt daraus beides — die PDF/A-3 zur Ansicht und das XML als Beleg. Dann können die beiden gar nicht auseinanderlaufen, und die PDF/A-Konformität ist eine Eigenschaft des Erzeugers, kein nachträglicher Reparaturversuch. Wie das abläuft, zeigt der Artikel ZUGFeRD-Rechnung erstellen.

PDF/A-3 und die Aufbewahrung

Die Formatwahl ist nicht nur eine Frage der Normkonformität. PDF/A ist für die Langzeitarchivierung gemacht, und genau darum geht es bei Rechnungen: acht Jahre unveränderte, lesbare Aufbewahrung. Eine ZUGFeRD-Rechnung erfüllt beide Anforderungen in einer Datei — lesbar für Menschen, auswertbar für Maschinen, archivfest.

Wichtig bleibt: Aufbewahrt wird die Originaldatei mit Anhang. Ein Ausdruck genügt nicht, eine neu erzeugte PDF ohne XML auch nicht.

Häufige Fragen

Stand: September 2026. Quellen: ISO 19005-1 bis -4 (PDF/A), ZUGFeRD-Spezifikation 2.5 (FeRD), Factur-X 1.07/1.08, EN 16931, BMF-Schreiben vom 15. Oktober 2024, veraPDF, Mustangproject 2.24.