ZUGFeRD ist ein hybrides E-Rechnungsformat: ein PDF/A-3 mit eingebettetem CII-XML nach EN 16931. Der Empfänger sieht ein normales PDF, die Software liest die strukturierten Daten aus dem eingebetteten XML. Factur-X ist derselbe Standard unter französischem Namen; ab Version 2.0.1 sind die Profile deckungsgleich.
ZUGFeRD verbindet zwei Welten in einem Dokument: das vertraute PDF und die strukturierten Daten, die eine E-Rechnung ausmachen. Dieser Beitrag erklärt, wie das Format aufgebaut ist, was es von XRechnung unterscheidet und ab welcher Version es zählt.
Ein Dokument, zwei Ebenen
ZUGFeRD ist ein hybrides Format: ein PDF/A-3 mit einem eingebetteten CII-XML nach der zugrundeliegenden Norm EN 16931. Das bedeutet:
- Ihr Kunde öffnet ein ganz normales PDF — den lesbaren Sichtbeleg.
- Die Software Ihres Kunden liest das eingebettete XML — die strukturierten Daten für die automatische Verarbeitung.
Damit erfüllt ein einziges Dokument beide Bedürfnisse, ohne dass Sie zwei Dateien verschicken.
ZUGFeRD und Factur-X: derselbe Standard
ZUGFeRD (Deutschland) und Factur-X (Frankreich) sind derselbe technische Standard unter zwei Namen. Ab Version 2.0.1 sind die Profile deckungsgleich — wer ZUGFeRD 2.0.1+ erzeugt, erzeugt zugleich Factur-X.
Die Versionsschwelle: ab 2.0.1
Nicht jede ZUGFeRD-Datei zählt als E-Rechnung im Sinne der Pflicht:
| Version | E-Rechnung nach EN 16931? |
|---|---|
| ZUGFeRD 1.0 | nein — erfüllt die EN 16931 nicht |
| ZUGFeRD ab 2.0.1 / Factur-X | ja — strukturiertes CII-XML nach EN 16931 |
Ein klassisches PDF ohne eingebettetes strukturiertes XML erfüllt die Pflicht in keinem Fall.
Die Profile: welche als E-Rechnung zählen
ZUGFeRD kennt mehrere Profile — sie legen fest, wie vollständig das eingebettete XML ist. Für die E-Rechnungspflicht ist entscheidend, dass das Profil die EN 16931 erfüllt:
| Profil | Datentiefe | E-Rechnung im Sinne der Pflicht? |
|---|---|---|
| MINIMUM | nur Kopf-/Summendaten | ❌ nein — reine Buchungshilfe |
| BASIC-WL | ohne Rechnungspositionen | ❌ nein — reine Buchungshilfe |
| BASIC | mit Rechnungspositionen | ✅ ja |
| EN 16931 (COMFORT) | vollständige EN-16931-Kerndaten | ✅ ja |
| EXTENDED | EN 16931 plus Zusatzfelder | ✅ ja |
| XRECHNUNG | Referenz-Profil (XRechnung) | ✅ ja |
Bereits BASIC ist eine EN-16931-konforme Untermenge und für einfache Rechnungen ausreichend; für breite Interoperabilität im B2B empfiehlt sich gleichwohl EN 16931 (COMFORT). Nicht anerkannt sind allein MINIMUM und BASIC-WL — beide sind reine Buchungshilfen: BASIC-WL enthält keine Rechnungspositionen, MINIMUM zusätzlich keine Aufschlüsselung der Umsatzsteuer.
Wichtig für den Empfang: Eine eingehende ZUGFeRD-Rechnung im Profil BASIC ist damit eine vollwertige E-Rechnung — sie als „nicht strukturiert“ zurückzuweisen, wäre falsch.
Versionsuntergrenze und Profilfilter gelten dabei kumulativ: Kein Profil aus ZUGFeRD 1.x qualifiziert, weil 1.x nicht auf der EN 16931 beruht — auch dann nicht, wenn der Profilname vertraut klingt. „COMFORT“ ist die Bezeichnung aus ZUGFeRD 1.0; im aktuellen 2.x heißt dasselbe Profil EN 16931. Wir führen den alten Namen hier nur zur Wiedererkennung mit.
ZUGFeRD oder XRechnung?
Beide erfüllen die EN 16931 — der Unterschied liegt in der Form:
- ZUGFeRD/Factur-X — hybrides PDF/A-3 mit Sichtbeleg; praktisch im B2B, wo ein lesbares PDF gewünscht ist.
- XRechnung — reines XML ohne Sichtbeleg; typisch im Behördenkontext (B2G). Siehe XRechnung erklärt.
Die ausführliche Gegenüberstellung inklusive Factur-X steht in XRechnung, ZUGFeRD und Factur-X im Vergleich. Beide Formate bilden dasselbe EN-16931-Datenmodell ab — deshalb entstehen sie bei Fortlauf aus einer gemeinsamen Datenquelle, und der Wechsel zwischen ihnen ist eine Ausgabe-Entscheidung, kein Datenmodell-Umbau.
Übertragung: ein normales PDF, ein zulässiger Weg
Erzeugung und Versand sind auch bei ZUGFeRD getrennt. Weil das Ergebnis ein normales PDF ist, ist der Versand per E-Mail besonders naheliegend — und für inländisches B2B ein zulässiger Weg; ein bestimmtes Übertragungsnetz ist nicht vorgeschrieben. Welche Wege zulässig sind, ordnet E-Rechnung übermitteln: E-Mail, Peppol und die zulässigen Wege ein.
ZUGFeRD programmatisch erzeugen
Den konkreten Request-Flow — anlegen, ausstellen, PDF/A-3 abholen — zeigt
ZUGFeRD 2.x / Factur-X per API erzeugen. Wie das
CII-XML technisch ins PDF kommt (PDF/A-3b, eingebettete Datei, XMP-Extension), erklärt
ZUGFeRD-PDF/A-3 erzeugen. Sprachspezifische Beispiele
für denselben drei-Call-Flow gibt es für
PHP, Node.js,
Python und Java — statt GET …/xml
holen Sie das PDF über GET …/pdf. Wie Belege gegen die EN-16931-Regeln geprüft werden,
erklärt KoSIT-Validierung erklärt.
Einordnung in die Pflicht
Wie ZUGFeRD in die E-Rechnungspflicht passt und ab wann sie greift, lesen Sie unter Compliance. Fortlauf erzeugt aktuelle ZUGFeRD-2.x-Profile aus einem sauberen EN-16931-Datenmodell — dasselbe Modell, aus dem auch die XRechnung entsteht.
Selbst ausprobieren? Der Zugang ist kostenlos und ohne Karte — Produkt-Einstieg für Entwickler →
Oder den eigenen Abrechnungsfluss konkret durchsprechen: 30 Min, technisch, mit dem Gründer →