Eigenes PDF-Design als ZUGFeRD/Factur-X

Viele Teams haben ein sorgfältig gestaltetes Rechnungs-PDF — Logo, Hausschrift, Fußzeile mit Zahlungsbedingungen — und stehen jetzt vor der Aufgabe, daraus eine E-Rechnung zu machen, ohne das Design aufzugeben. Genau dafür sind ZUGFeRD und Factur-X gebaut: hybride Rechnungen, die für Menschen aussehen wie bisher und für Maschinen ein strukturiertes XML mitführen. Der Weg dorthin ist gut spezifiziert, scheitert in der Praxis aber regelmäßig an einer Handvoll Details.

Anatomie: PDF/A-3 plus eingebettetes CII-XML

Eine ZUGFeRD/Factur-X-Rechnung besteht aus drei Schichten:

Der Container ist ein PDF/A-3. Nicht PDF 1.4, nicht PDF 1.7, sondern die Archivierungsnorm ISO 19005-3 — sie ist die einzige PDF/A-Variante, die beliebige Dateianhänge erlaubt. PDF/A-3 verbietet außerdem Verschlüsselung, JavaScript und externe Abhängigkeiten wie nicht eingebettete Schriften.

Das eingebettete XML ist eine UN/CEFACT-CII-Datei und trägt einen normierten Dateinamen, der von Standard und Version abhängt: factur-x.xml bei ZUGFeRD 2.1+ und Factur-X (im Profil XRECHNUNG: xrechnung.xml), zugferd-invoice.xml bei ZUGFeRD 2.0, ZUGFeRD-invoice.xml beim veralteten ZUGFeRD 1.0. Der Anhang braucht einen AFRelationship-Eintrag — bei vollwertigen Profilen üblicherweise Alternative (das XML ist eine alternative Repräsentation derselben Rechnung), bei den reduzierten Profilen MINIMUM und BASIC WL dagegen Data oder Source.

Die XMP-Metadaten des PDFs deklarieren über das Factur-X-Extension-Schema, was eingebettet ist: DocumentType (INVOICE), DocumentFileName (exakt der Anhangsname), Version und ConformanceLevel — also das Profil, von MINIMUM bis EXTENDED. Empfängersysteme lesen diese Deklaration, bevor sie das XML überhaupt anfassen.

Die klassischen Stolperfallen

Fast alle fehlerhaften Hybridrechnungen fallen in eines dieser Muster:

• Normales PDF statt PDF/A-3. Der Rechnungs-Renderer erzeugt PDF 1.4/1.7, das XML wird „irgendwie” angehängt. Manche Empfänger extrahieren es trotzdem, konforme Prüfungen lehnen ab.
• Fehlende oder falsche XMP-Deklaration. Das XML ist da, aber die XMP-Metadaten fehlen oder nennen einen anderen Dateinamen — für strikte Empfänger ist das kein ZUGFeRD/Factur-X.
• Falscher Anhangsname. rechnung.xml oder invoice.xml statt factur-x.xml. Der Inhalt mag perfekt sein, gefunden wird er nicht überall.
• Profil-Mismatch. Das XML deklariert über die CustomizationID (BT-24) Profil EN 16931, das XMP sagt BASIC — zwei Wahrheiten, denen Empfänger unterschiedlich glauben. Welche Profile überhaupt als E-Rechnung gelten, erklärt der Profil-Guide; MINIMUM und BASIC WL meldet der Validator als BH-PROFILE-01.
• Verschlüsselte PDFs. Passwortschutz klingt nach Sicherheit, macht das eingebettete XML aber unlesbar — und ist in PDF/A-3 ohnehin verboten. Billhorse meldet das explizit als BH-PDF-02.

Werkzeugwege

Das Rad muss niemand neu erfinden. Im Java-Umfeld sind mustangproject und PDFBox etablierte Wege, ein bestehendes PDF nach PDF/A-3 zu konvertieren und das XML samt AFRelationship und XMP anzuhängen; für .NET und Python existieren vergleichbare Bibliotheken. Das Prinzip ist immer dasselbe: Design-PDF rendern wie bisher, dann in einem zweiten Schritt Container konvertieren, XML einbetten, XMP schreiben.

Eine Priorität sollte dabei klar sein: Der maschinenlesbare Teil ist das, was Empfänger tatsächlich verarbeiten — das Design ist nur fürs Auge. Die Sorgfalt gehört ins XML: korrekte Summenarithmetik, vollständige Pflichtfelder, das richtige Profil. Ein schönes PDF mit kaputtem XML ist keine E-Rechnung; ein nüchternes PDF mit sauberem XML schon.

Prüf-Workflow: das Ergebnis gegenprüfen

Das erzeugte PDF gehört vor dem Versand in den Billhorse-Validator: Er extrahiert das eingebettete XML direkt aus dem PDF-Container und validiert es gegen EN 16931 und die profilspezifischen Regeln — komplett im Browser, ohne Upload. Findet sich kein Rechnungs-XML im PDF, ist das Ergebnis BH-PDF-01 — das häufigste Symptom eines Erzeugungswegs, der das Einbetten schlicht vergessen hat. Ist das PDF verschlüsselt, wird das nicht als diffuser Parse-Fehler, sondern explizit als BH-PDF-02 gemeldet. Sinnvoll ist der Test mit echten Grenzfällen: Rechnung mit Rabatt, Gutschrift, Rechnung mit mehreren Steuersätzen — dort zeigen sich Mapping-Fehler, die das Standardbeispiel nicht triggert.

Pflicht: Sichtteil und XML müssen übereinstimmen

Ein Punkt ist keine Stilfrage, sondern Pflicht: Sichtbares PDF und eingebettetes XML müssen dieselbe Rechnung beschreiben. Rechtlich maßgeblich ist der strukturierte Teil — weicht das Sichtbild ab, gilt das XML. Divergenzen entstehen fast immer dann, wenn PDF und XML aus getrennten Codepfaden erzeugt werden: Das PDF rundet anders, das XML kennt den Rabatt nicht, eine Position fehlt. Die robuste Architektur rendert beide Repräsentationen aus derselben Datenquelle — ein Rechnungsmodell, zwei Ausgaben. Wer das von Anfang an so baut, muss Konsistenz nie wieder manuell prüfen.

← Alle Guides · Stand: 2026-07-04