Eine Datei, zwei Leser
Die Grundidee von ZUGFeRD ist eine Antwort auf ein praktisches Problem: Die Buchhaltung will Daten, der Mensch will einen Beleg. Zwei getrennte Dateien bedeuten zwei Wege, zwei Ablagen und irgendwann zwei Wahrheiten.
ZUGFeRD legt beides in eine Datei. Sichtbar ist ein ganz normales PDF. Darin eingebettet liegt eine vollständige XML-Rechnung. Wer die Datei per Mail bekommt und öffnet, sieht den Beleg. Wer sie in ein Buchhaltungssystem zieht, bekommt Felder.
1rechnung.pdf (PDF/A-3)2├── sichtbare Seiten → für den Menschen3└── factur-x.xml (eingebettet) → für die Maschine (CII-Syntax)Der Träger ist PDF/A-3. Das ist keine beliebige Entscheidung: PDF/A-3 ist die einzige PDF-Variante, die das Einbetten beliebiger Dateien erlaubt und zugleich archivtauglich ist.
Das XML ist das Original
Diese Reihenfolge ist wichtiger, als sie klingt. In einer ZUGFeRD-Datei ist das eingebettete XML der maßgebliche Teil; das sichtbare PDF ist seine Darstellung.
Daraus folgt zweierlei:
🔴 Ein Auseinanderlaufen ist ein echter Fehler. Wenn das PDF 1.190 € zeigt und das XML 1.109 € enthält, prüft der Mensch das eine und bucht die Maschine das andere. Beides passiert, ohne dass jemand widerspricht.
🔵 Aufbewahrt wird die Datei als Ganzes. Ein Ausdruck genügt nicht, ein extrahiertes XML ohne PDF ebenso wenig — das Original ist die Kombination.
Die Profile entscheiden
Nicht jede ZUGFeRD-Datei ist eine E-Rechnung. Das Format kennt gestaffelte Profile, die festlegen, wie viel strukturierte Information mitreist:
| Profil | Positionen | Vollwertige E-Rechnung? |
|---|---|---|
| MINIMUM | nein | 🔴 nein |
| BASIC WL | nein | 🔴 nein |
| BASIC | ja | 🟡 eingeschränkt |
| EN 16931 | ja | 🟢 ja |
| EXTENDED | ja | 🟢 ja, mit Vorbehalt |
| XRECHNUNG | ja | 🟢 ja, auch für Behörden |
MINIMUM und BASIC WL wurden als Buchungshilfen geschaffen, nicht als Rechnungen. Sie tragen kaum mehr als Absender, Summen und Datum. Eine Datei in diesen Profilen sieht aus wie eine E-Rechnung, trägt das Logo und öffnet sich normal — und wird von einem prüfenden Empfänger zurückgewiesen.
Wer die E-Rechnungspflicht erfüllen will, gibt EN 16931 als Untergrenze vor.
ZUGFeRD, XRechnung, Factur-X
Die drei Namen verwirren, weil sie auf unterschiedlichen Ebenen liegen:
- XRechnung ist ein Regelwerk (eine CIUS) und technisch reines XML.
- ZUGFeRD ist ein Dateiformat — ein PDF mit eingebettetem XML.
- Factur-X ist derselbe Standard wie ZUGFeRD unter französischem Namen.
Sie schließen einander nicht aus. Das ZUGFeRD-Profil XRECHNUNG erzeugt eine
Datei, die beides ist: ein lesbares PDF und eine konforme XRechnung. Für
Unternehmen, die an Behörden und an Firmenkunden fakturieren, ist das der Weg, mit
einem Ausgabeformat auszukommen.
Wo es in der Praxis klemmt
Das XML wird aus dem PDF abgeleitet. Wer ein fertiges PDF nimmt und die Werte per Texterkennung zurückliest, erzeugt ein XML aus geratenen Daten. Der richtige Weg ist umgekehrt: Aus den strukturierten Daten entstehen PDF und XML gemeinsam.
Das Profil ist zu klein gewählt. Häufig, weil MINIMUM am schnellsten umzusetzen war und niemand später geprüft hat, ob das reicht.
Der Empfänger sieht nur das PDF. Manche Eingangsverarbeitungen behandeln eine ZUGFeRD-Datei wie ein gewöhnliches PDF und ignorieren die eingebetteten Daten. Das ist kein Fehler Ihrer Datei — aber es erklärt, warum der Empfänger trotz E-Rechnung nach Daten fragt.
Die Datei ist kein PDF/A-3. Ein normales PDF mit Anhang genügt nicht. Ohne PDF/A-3-Konformität scheitert die Prüfung, bevor das XML überhaupt gelesen wird.
Prüfen
Bei ZUGFeRD prüft ein Validator zwei Dinge getrennt: ob die PDF-Hülle PDF/A-3-konform ist und ob das eingebettete XML den Regeln seines Profils genügt. Beide können unabhängig voneinander scheitern — und die Meldung sagt Ihnen, welcher der beiden Teile gemeint ist.