PDF/A-3B und ZUGFeRD: ist meine E-Rechnungs-PDF wirklich konform? (veraPDF)

ZUGFeRD ist eine hybride Rechnung: eine für Menschen lesbare PDF plus die maschinenlesbare XML im Inneren. Der PDF-Teil muss dabei eine besondere Archiv-Variante sein – PDF/A-3. Genau hier entstehen die meisten Missverständnisse.

> Kurzantwort: Damit eine PDF wirklich PDF/A-3(-B) ist, müssen unter anderem alle Schriftarten eingebettet sein, ein OutputIntent/ICC-Farbprofil vorhanden sein und passende PDF/A-Metadaten. Ein Validator wie veraPDF prüft das, repariert aber nichts. Ist die Ausgangs-PDF nicht konform (z. B. nicht eingebettete Schriften), hilft nur eine echte Konvertierung – oder Sie nutzen reine XRechnung.

Was PDF/A-3 verlangt

PDF/A ist dafür gemacht, dass ein Dokument auf jedem Rechner und in vielen Jahren identisch dargestellt wird. Dafür gelten strenge Regeln, die wichtigsten:

1. Alle Schriftarten eingebettet – die Datei muss die Schriftdaten selbst enthalten und darf sich nicht darauf verlassen, dass der Leser z. B. Arial installiert hat.
2. OutputIntent / ICC-Farbprofil – die Datei muss festlegen, wie Farben reproduziert werden.
3. PDF/A-XMP-Metadaten – die Kennzeichnung als PDF/A-3.

Der häufige Stolperstein: nicht eingebettete Schriften

Ältere Warenwirtschafts- und Fakturasysteme erzeugen häufig PDFs, die auf Systemschriften wie Arial oder Arial Bold verweisen, sie aber nicht einbetten. Eine solche Datei ist bereits nicht PDF/A-konform – und das lässt sich nicht dadurch heilen, dass man nur die ZUGFeRD-XML und PDF/A-Metadaten ergänzt.

Validieren ist nicht Konvertieren

Ein wichtiger Punkt: veraPDF validiert nur, es konvertiert nicht. Ein Validator meldet „nicht konform“, macht aus einer nicht-konformen Datei aber keine konforme. Um wirklich PDF/A-3 zu erzeugen, braucht es einen echten Konvertierungsschritt, der Schriften einbettet und ein Farbprofil hinzufügt (z. B. mit Ghostscript oder der ZUGFeRD-Referenzbibliothek Mustangproject).

Was immer stimmt: die XML

Unabhängig vom PDF-Container ist der entscheidende, rechtlich maßgebliche Teil die strukturierte XML. Diese wird bei TaxLayer vollständig gegen den KoSIT-Prüfstandard und die EN 16931 validiert (0 Fehler). Die Rechnungsdaten selbst sind damit korrekt und konform – die PDF/A-Frage betrifft nur die äußere Hülle.

So kommen Sie sicher zum Ziel

• Variante A – PDF/A aus dem System exportieren: Kann Ihr Warenwirtschaftssystem die Rechnung als PDF/A (mit eingebetteten Schriften) ausgeben, ist die daraus erzeugte ZUGFeRD-Datei konform.
• Variante B – reine XRechnung nutzen: Bei der XRechnung (reines XML) entfällt der PDF-Container vollständig; die Frage der PDF/A-Konformität stellt sich nicht.

Fazit

PDF/A-3 ist mehr als ein Etikett: Es verlangt eingebettete Schriften, ein Farbprofil und die richtigen Metadaten. Wer aus einem älteren System kommt, exportiert am besten direkt PDF/A – oder setzt auf XRechnung, wo der PDF-Container keine Rolle spielt.

---

Die E-Rechnungs-XML ist bei TaxLayer immer EN-16931- und KoSIT-validiert. Fragen zur PDF/A-Konformität? Schreiben Sie an info@landauer.de.