XRechnung vs. ZUGFeRD: Unterschiede und welches Format Sie brauchen

Ein semantisches Modell, zwei Verpackungen

EN 16931-1 definiert Geschäftsbegriffe und Regeln, keine Dateien. Jede Tatsache auf der Rechnung hat eine Kennung — BT-1 Rechnungsnummer, BT-10 Käuferreferenz, BT-31 USt-IdNr. des Verkäufers, BT-112 Gesamtbetrag inklusive Steuer — und die Norm legt Bedeutung, Kardinalität und rechnerische Beziehungen fest. Normativ sind zwei Syntaxbindungen: OASIS UBL 2.1 und UN/CEFACT Cross Industry Invoice (CII) D16B.

XRechnung ist eine CIUS — eine Core Invoice Usage Specification — der KoSIT für die deutsche öffentliche Verwaltung. Eine CIUS darf die Norm nur einschränken: optionale Felder verpflichtend machen, Felder verbieten, Codelisten verengen. Neue Semantik darf sie nicht erfinden. XRechnung unterstützt beide Syntaxen und ergänzt rund 30 zusätzliche Geschäftsregeln.

ZUGFeRD 2.x (inhaltlich identisch mit dem französischen Factur-X) ist keine CIUS, sondern eine Container-Spezifikation. Sie beschreibt, wie eine CII-XML-Instanz an ein PDF/A-3 angehängt wird, sodass ein Mensch die Seite liest und eine Maschine den Anhang. Das XML in einer ZUGFeRD-Datei ab Profil EN 16931 ist selbst ein EN-16931-konformes CII-Dokument — eine ZUGFeRD-Datei kann also einen XRechnung-konformen Inhalt transportieren.

Dieser letzte Punkt löst die meiste Verwirrung auf. Die Frage lautet selten „XRechnung oder ZUGFeRD“, sondern: welche Syntax, in welchem Profil, in welchem Container, über welchen Kanal.

• Semantik: EN-16931-Geschäftsbegriffe (BT-*) und Regeln (BR-*)
• Syntax: UBL 2.1 oder UN/CEFACT CII D16B
• Profil: XRechnung-CIUS, ZUGFeRD MINIMUM…EXTENDED, Peppol BIS
• Container: reine .xml-Datei oder PDF/A-3 mit eingebettetem Anhang

Aufbau einer XRechnung-Datei

Eine XRechnung-Instanz ist ein einzelnes UTF-8-XML-Dokument, typisch 8–40 KB. In UBL-Syntax ist das Wurzelelement <Invoice>, cbc:CustomizationID trägt die Spezifikationskennung — die Zeichenkette, die dem Validator sagt, welches Regelwerk gilt. Eine falsche Kennung ist eine der häufigsten Ursachen für Ablehnungen ohne erkennbaren Feldfehler: Der Prüfer wendet das falsche Profil an oder verweigert die Annahme.

Strukturell zerfällt das Dokument in vier Blöcke: Kopfdaten (Nummer, Datum, Typcode 380 für die Handelsrechnung, Währung, Käuferreferenz), Parteien (Verkäufer und Käufer mit Firmierung, Anschrift, Steuerregistrierung und elektronischer Adresse), Positionen (je mit Menge, Einheitencode nach UN/ECE-Empfehlung 20, Nettoeinzelpreis und Steuerkategorie) sowie die Summenblöcke mit der Steueraufschlüsselung je Kategorie.

Die Leitweg-ID steht in BT-10, der Käuferreferenz. Sie ist eine Routing-Kennung der Verwaltungseinheit, keine Kundennummer, und im deutschen B2G verpflichtend. Ohne sie erreicht die Rechnung die richtige Buchungsstelle nicht, selbst wenn alle anderen Regeln erfüllt sind.

Da es sich um reines XML handelt, gibt es keine visuelle Darstellung. Für Behörden ist das kein Problem: Ihre Portale rendern das XML per Stylesheet. Reines XML an einen kleinen Privatkunden ohne ERP führt dagegen zuverlässig zu einer Rückfrage nach „der richtigen Rechnung“.

Wie die PDF/A-3-Einbettung bei ZUGFeRD funktioniert

PDF/A-3 ist die Archiv-Teilmenge von PDF, die — anders als PDF/A-2 — beliebige Dateianhänge mit einem /AFRelationship-Qualifier erlaubt. Genau das nutzt ZUGFeRD: Das XML wird als EmbeddedFile-Stream eingebettet, im /AF-Array des Dokumentkatalogs referenziert und mit /AFRelationship /Alternative gekennzeichnet — der Anhang ist also eine alternative Darstellung des sichtbaren Inhalts, keine bloße Ergänzung.

Der Dateiname des Anhangs ist normativ und entscheidend: factur-x.xml für Factur-X und aktuelle ZUGFeRD-Versionen, zugferd-invoice.xml findet sich noch bei Systemen aus der 2.0-Ära. Empfangssoftware sucht exakt diesen Namen. Ein korrektes PDF mit kreativ benanntem XML-Anhang gilt für die meisten Eingangsparser als gewöhnliches PDF.

Zweite Voraussetzung sind XMP-Metadaten. Das XMP-Paket auf Dokumentebene muss das Factur-X-/ZUGFeRD-Erweiterungsschema mit DocumentType, DocumentFileName, Version und ConformanceLevel (dem Profil) enthalten. Parser entscheiden daran, ob sie dem Anhang vertrauen. Fehlendes XMP ist die zweithäufigste Ursache dafür, dass Hybridrechnungen stillschweigend ignoriert werden.

PDF/A-3 bringt zudem Archivpflichten mit: eingebettete, subsetfähige Schriften, geräteunabhängige Farbe über einen Output Intent, kein JavaScript, keine Verschlüsselung, keine externen Verweise. Deshalb kann eine Hybridrechnung kein passwortgeschütztes PDF sein — Verschlüsselung bricht die PDF/A-Konformität.

Sichtbare Seite und XML müssen übereinstimmen. Das Dateiformat erzwingt das nicht: Ein PDF kann 1.190,00 EUR zeigen, während der Anhang 1.090,00 sagt. Bei Abweichungen ist im strukturierten Austausch das XML der rechtlich maßgebliche Datensatz — und die Differenz eine Prüfungsfeststellung mit Ansage. Erzeugen Sie beides aus einer Datenquelle und bearbeiten Sie das PDF niemals nachträglich.

Die ZUGFeRD-Profilstufen

ZUGFeRD 2.x definiert Profile, die sich im Umfang der befüllten EN-16931-Felder unterscheiden. MINIMUM und BASIC WL enthalten nur Buchungshilfen — Summen, Parteien, Zahlungsbedingungen — ohne Positionen; sie sind ausdrücklich keine Rechnungen im umsatzsteuerlichen Sinn. BASIC ergänzt Positionen bei eingeschränkten Codelisten. EN 16931 (früher COMFORT) ist das vollständig normkonforme Profil. EXTENDED geht für komplexe Konzern- und Logistikfälle darüber hinaus.

Auf die Frage „welches Profil erzeuge ich“ lautet die Antwort EN 16931, sofern kein Partner ausdrücklich EXTENDED verlangt. Darunter erfüllt die Rechnung die europäische Norm nicht — und genau der Automatisierungsnutzen, der die Umstellung motiviert hat, entfällt.

Es gibt außerdem die Kombination XRechnung-CIUS im ZUGFeRD-Container: ein PDF/A-3, dessen eingebettetes CII zusätzlich die XRechnung-Regeln inklusive Leitweg-ID erfüllt. Das ist das portabelste Einzelartefakt, das sich erzeugen lässt, und die sinnvolle Voreinstellung für deutsche Empfänger.

• MINIMUM / BASIC WL — nur Buchungshilfe, keine gültige Rechnung
• BASIC — Positionen vorhanden, eingeschränkte Codelisten
• EN 16931 — voll konform, die sinnvolle Voreinstellung
• EXTENDED — Obermenge für komplexe Logistik- und Konzernfälle

Validierung verhält sich je Artefakt unterschiedlich

Reines XML wird zweistufig geprüft: XSD-Schemavalidierung, dann Schematron mit den EN-16931-Regeln plus CIUS-Overlay. Fast alle realen Fehler entstehen in der zweiten Stufe — Beträge, die nicht aufgehen, eine fehlende Steueraufschlüsselung für eine verwendete Kategorie, ein fehlender Befreiungsgrund bei Nullsteuer, ein Fälligkeitsdatum vor dem Rechnungsdatum.

Bei Hybriddateien kommen zwei Stufen davor: Zuerst muss der Container auf PDF/A-3-Konformität geprüft werden, üblicherweise mit veraPDF. Dann muss der Anhang über das /AF-Array gefunden und die XMP-Deklaration gegen das tatsächliche Profil abgeglichen werden. Erst danach folgt die XML-Prüfung. Eine Hybridrechnung kann also scheitern, wie reines XML es nie kann: gültiges XML, ungültiger Container.

Der E-Rechnungs-Reader von Toolula führt die XML-seitigen Prüfungen vollständig im Browser aus: Er nimmt UBL oder CII an, extrahiert den Anhang aus einem Hybrid-PDF, ordnet jeden Wert seiner BT-Kennung zu und listet auf, welche Regeln warum scheitern. Da die Verarbeitung per WebAssembly auf Ihrem Gerät läuft, verlassen sensible Rechnungen den Rechner nicht — hier besonders relevant, weil Rechnungs-XML vollständige Kundendaten, Bankverbindungen und margenverratende Einzelpreise enthält.

Ein Versand-Workflow für beide Welten

Schritt eins: Empfänger klassifizieren. Deutsche Behörde: XRechnung ist Pflicht, die Leitweg-ID muss vor der Ausstellung vorliegen. Behörde in einem anderen EU-Staat: EN 16931 über Peppol, gegebenenfalls mit nationaler CIUS. Privatwirtschaftliches Unternehmen: hybrides ZUGFeRD im Profil EN 16931. Verbraucher: ein einfaches PDF genügt.

Schritt zwei: Routingdaten einmal je Kunde erfassen, nicht je Rechnung. Leitweg-ID, Peppol-Teilnehmerkennung, USt-IdNr., geforderte Bestellreferenz (BT-13) und Übertragungsweg gehören in den Kundendatensatz. Die meisten B2G-Ablehnungen entstehen, weil Routingdaten jedes Mal neu aus einer E-Mail abgetippt werden.

Schritt drei: aus einem einzigen Datenobjekt erzeugen. Zuerst die semantische Rechnung bilden, dann serialisieren — nach UBL oder CII für reines XML, nach CII plus gerenderter Seite für die Hybriddatei. Niemals das PDF im einen und das XML im anderen Werkzeug erzeugen; genau so driften sichtbare und strukturierte Summen auseinander.

Schritt vier: vor dem Versand validieren, nicht nach der Ablehnung. Rechnerische Abstimmung, Steueraufschlüsselung und Profilkennung jedes Mal prüfen. Schritt fünf: beide Artefakte zusammen mit dem Übermittlungsnachweis archivieren, für die nationale Aufbewahrungsfrist — in Deutschland in der Regel acht Jahre, sonst in der EU meist sechs bis zehn. Im strukturierten Austausch ist das XML das Original; ein Ausdruck genügt nicht.

So konfiguriert schrumpft die Formatfrage auf ein Feld im Kundendatensatz zusammen. Rechnungslogik, steuerliche Behandlung und Prüfroutine bleiben identisch, ob am Ende eine reine XRechnung oder ein hybrides ZUGFeRD-PDF steht.

Häufig gestellte Fragen