XRechnung oder ZUGFeRD? Der ehrliche Vergleich – wann was und warum
Über 90 % der deutschen B2B-E-Rechnungen laufen über ZUGFeRD. Das ist kein Zufall. Was hinter dieser Zahl steckt, wann XRechnung trotzdem Pflicht ist – und welches Manipulationsrisiko reines XML birgt.
Kurz-Antwort für eilige Leser
ZUGFeRD für fast alle B2B-Fälle — lesbar ohne Viewer, DMS-kompatibel, E-Mail-tauglich, GoBD-konform archivierbar.
XRechnung wenn der Empfänger es fordert oder es sich um eine Bundesbehörde handelt — dort ist es gesetzliche Pflicht.
Der entscheidende Unterschied: Hybrid vs. reines XML
Beide Formate erfüllen die gleiche gesetzliche Anforderung: strukturierte Rechnungsdaten nach EN 16931. Der Unterschied liegt darin, wie diese Daten verpackt werden.
ZUGFeRD / Factur-X
Hybridformat — PDF/A-3 + XML in einer Datei
Das PDF enthält ein eingebettetes XML (UN/CEFACT CII)
Mensch liest das PDF — Maschine liest das XML
Eine einzige Datei für beide Zwecke
Jeder PDF-Reader kann sie öffnen
Aktuell: ZUGFeRD 2.4 / Factur-X 1.08 (seit 15.01.2026)
XRechnung
Reines XML — kein visueller Anteil
Nur strukturiertes XML — kein PDF, kein visueller Anteil
Mit Texteditor öffenbar — aber für Menschen kaum lesbar
Zwei Varianten: UN/CEFACT CII (wie ZUGFeRD) oder UBL 2.1
PEPPOL: vor allem ein eigener sicherer Übertragungsweg — verwendet UBL 2.1 als XML-Format (BIS 3.0)
Entwickelt von KoSIT, aktuell Version 3.0.2 (April 2026)
Pflichtformat für B2G (Bundesbehörden) seit Nov. 2020
Warum über 90 % im B2B auf ZUGFeRD setzen
Für die meisten Unternehmen ist ZUGFeRD nicht die komplizierte Wahl — es ist die einfachere. Der Grund ist strukturell: ZUGFeRD passt in bestehende Prozesse, XRechnung erfordert neue Infrastruktur.
Lesbar ohne Zusatzsoftware
Eine ZUGFeRD-Rechnung öffnet jeder Empfänger mit seinem gewohnten PDF-Reader — Adobe, Preview, Browser, egal. Für XRechnung braucht er einen spezialisierten Viewer, ein ERP-System, das es anzeigt, oder Zugang zum OZG-RE-Visualisierungstool. Das klingt nach einer Kleinigkeit; in der Praxis bedeutet es, dass viele Empfänger XRechnungen schlicht nicht öffnen können.
E-Mail-Workflow bleibt erhalten
ZUGFeRD-Rechnungen werden wie gewohnt per E-Mail als Anhang verschickt. Der Empfänger sieht die Rechnung sofort — und seine Buchhaltungssoftware liest das eingebettete XML automatisch aus. Mit XRechnung geht das zwar technisch auch, aber der Empfänger kann die Datei ohne weiteres nicht einfach öffnen.
DMS-Integration ohne Mehraufwand
PDF/A-3 ist ein ISO-normiertes Langzeitarchivformat. ZUGFeRD-Dateien können direkt in bestehende Dokumenten-Management-Systeme abgelegt werden — ohne Konvertierung, ohne separate XML-Ablage, ohne neue Prozesse. Das Buchhaltungssystem liest das XML aus derselben Datei, die bereits im DMS liegt.
Gleichzeitige Nutzbarkeit
Die Stärke des Hybridformats: Dieselbe Datei dient dem Buchhalter als lesbarer Beleg, dem ERP als maschinenlesbarer Datensatz und dem DMS als revisionssicheres Archivdokument — alles aus einer einzigen Datei, ohne Medienbruch.
Wann ist XRechnung Pflicht?
XRechnung ist verpflichtend für Rechnungen an Bundesbehörden (B2G) — und nur dort. Die Pflicht gilt seit dem 27. November 2020. Einreichung erfolgt über das zentrale Rechnungseingangsportal des Bundes (ZRE) oder die OZG-konforme Plattform (OZG-RE), mit zwingender Leitweg-ID als Routing-Information.
Landesbehörden und Kommunen: immer mehr akzeptieren ZUGFeRD
Auf Bundesebene ist XRechnung Pflicht — darunter gibt es erheblichen Spielraum. Viele Landes- und Kommunalbehörden haben ZUGFeRD EN 16931 als gleichwertiges Eingangsformat freigegeben, weil es sich einfacher verarbeiten lässt: Das PDF ist sofort lesbar, eine Visualisierung ist nicht nötig, und bestehende DMS-Systeme können die Datei direkt ablegen.
Bayern
Akzeptiert ZUGFeRD EN 16931 über das E-Rechnungsportal des Freistaats
Baden-Württemberg
ZUGFeRD EN 16931 und XRechnung beide zugelassen
Nordrhein-Westfalen
ZUGFeRD wird in vielen Kommunalportalen akzeptiert
Sachsen, Thüringen u. a.
Zunehmende Akzeptanz über OZG-RE-kompatible Portale — im Einzelfall prüfen
Maßgeblich ist immer die Auftragsbestätigung oder das Landesportal
Die Akzeptanzlage ändert sich schnell — die obige Liste ist ein Richtwert, keine Garantie. Klären Sie vor der ersten Einreichung beim jeweiligen Auftraggeber oder dessen Portal, welche Formate akzeptiert werden. Für Bundesbehörden gilt weiterhin XRechnung über ZRE oder OZG-RE, ohne Ausnahme.
Für B2B gilt: Ab 01.01.2027 (Umsatz über 800.000 €) bzw. 01.01.2028 (alle Unternehmen) muss eine strukturierte E-Rechnung nach EN 16931 versendet werden — XRechnung und ZUGFeRD sind beide zulässig. Es gibt keine gesetzliche Präferenz für das eine oder das andere.
Merksatz: Die gesetzliche Pflicht ab 2027/2028 sagt „EN 16931-konform" — sie sagt nicht „XRechnung". Wer ZUGFeRD EN 16931 versendet, erfüllt die Pflicht vollständig.
Das Sicherheitsproblem: reines XML ist leicht zu verändern
Hier liegt ein Risiko, das in der öffentlichen Diskussion zu wenig Aufmerksamkeit bekommt. XML-Dateien sind Klartext — mit jedem Texteditor öffenbar. Für Menschen sind sie zwar schwer lesbar, aber gezielt einzelne Felder zu finden und zu ändern ist trivial: Ein Angreifer muss nur nach IBAN suchen und den Wert ersetzen — ohne Spuren zu hinterlassen, ohne dass es dem Empfänger auffällt.
Reales Angriffsszenario: IBAN-Betrug bei XRechnungen
Ein Angreifer fängt eine XRechnung per E-Mail ab (Man-in-the-Middle), öffnet das XML, ändert die IBAN in <ram:IBANID> auf ein eigenes Konto und sendet die Datei weiter. Das Buchhaltungssystem des Empfängers verarbeitet die Rechnung automatisch — auf die gefälschte Bankverbindung. Da kein lesbares PDF als visueller Referenzpunkt existiert, fällt die Abweichung nicht auf. Das Linux-Magazin berichtete im April 2025 konkret über diese Sicherheitsmängel; im Juli 2025 dokumentierte der Born's IT-Blog eine aktive Betrugsmasche mit genau diesem Muster.
Bei ZUGFeRD ist dieses Risiko strukturell geringer: Das PDF zeigt dem Empfänger die IBAN visuell — ein manueller oder automatischer Abgleich zwischen dem, was der Mensch sieht, und dem, was das System einliest, ist möglich. Ein Angreifer müsste sowohl das eingebettete XML als auch das sichtbare PDF konsistent manipulieren — deutlich aufwändiger.
GoBD und die Manipulierbarkeit von XML
Die GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern) verlangt, dass Buchungsbelege unveränderlich und vollständig aufbewahrt werden. Für E-Rechnungen bedeutet das:
E-Rechnungen müssen im maschinell auswertbaren Originalformat archiviert werden — eine Konvertierung in ein anderes Format für die Archivierung ist unzulässig.
Unveränderlichkeit muss aktiv sichergestellt sein — ein revisionssicheres DMS oder eine Write-Once-Speicherlösung ist erforderlich. Eine einfache Ablage im Dateisystem reicht nicht.
Ein reines XML, das in einem Ordner liegt, bietet keine inhärente Schutzfunktion gegen nachträgliche Änderungen. Wer GoBD-konform archiviert, braucht explizit eine Systemlösung, die Änderungen verhindert und protokolliert.
Aufbewahrungsfrist: 10 Jahre für steuerrelevante Belege.
Praxishinweis: ZUGFeRD hat hier einen praktischen Vorteil: PDF/A-3 ist ein ISO-normiertes Archivformat, das von den meisten DMS-Systemen nativ als archivwürdig erkannt und geschützt abgelegt wird. Das eingebettete XML ist damit automatisch mitarchiviert. Bei reinem XML muss die Revisionssicherheit explizit durch das System gewährleistet sein — sie folgt nicht aus dem Format selbst.
Wie man XML-Manipulation technisch verhindert
Wer XRechnung einsetzt — weil der Empfänger es fordert oder weil es B2G-Pflicht ist — kann das Manipulationsrisiko durch technische Maßnahmen senken. Die Maßnahmen unterscheiden sich stark in ihrer Praxistauglichkeit:
PEPPOL-Netzwerk statt E-Mail
EmpfohlenPEPPOL ist primär ein eigener sicherer Übertragungsweg — kein XML-Format, sondern ein Netzwerk zertifizierter Access Points mit verschlüsselter, authentifizierter Übertragung. Als XML-Format wird dabei UBL 2.1 (BIS 3.0) verwendet. Eine Manipulation unterwegs ist kryptografisch ausgeschlossen. Das ist der einzige Weg, der ohne Abstriche funktioniert.
Vier-Augen-Prinzip bei Zahlungen
EmpfohlenIBAN im eingegangenen XML gegen den Lieferantenstammsatz im eigenen System abgleichen, bevor die Zahlung freigegeben wird. Einfach, ohne Infrastrukturaufwand, wirksam — und in der Praxis der zuverlässigste Schutz gegen IBAN-Betrug.
Kryptografischer Hash
Mit EinschränkungenBeim Versand wird ein Hash der Datei erzeugt — der Empfänger kann prüfen, ob die Datei unterwegs verändert wurde. Theoretisch wirksam. In der Praxis stoßen viele Empfangssysteme bei Hash-Prüfungen auf Probleme; ein mitgeschickter Hash (z. B. als separater Anhang) wird häufig ignoriert oder vom System nicht verarbeitet. Gut zu kennen und zu verstehen — als primäres Schutzmittel aber unzuverlässig.
Digitale Signatur (QES)
AufwändigEine qualifizierte elektronische Signatur nach eIDAS macht nachträgliche Änderungen nachweisbar. Praxishürde: Zertifikat erforderlich, Empfänger muss die Signatur aktiv prüfen — was die meisten Empfangssysteme nicht automatisch tun.
Unser Ansatz: PDF und XML automatisch gegenprüfen
Das FeRD empfiehlt ausdrücklich, eigene Prüfmechanismen zur Sicherstellung der inhaltlichen Identität zwischen dem sichtbaren und dem maschinenlesbaren Rechnungsanteil einzuführen. Wir setzen das in unserem Validator um: Bei ZUGFeRD-Dokumenten prüfen wir, ob das eingebettete XML inhaltlich mit dem, was im PDF steht, übereinstimmt. In der Praxis laufen PDF und XML häufiger auseinander als erwartet — meistens durch IT-Fehler im erzeugenden System, in einzelnen Fällen auch betrügerisch. Diese Diskrepanz-Prüfung ist ein wesentlicher Teil unserer Validierungslogik.
Bestehende PDFs zu ZUGFeRD machen
Gerade bei komplexen Rechnungen, mehrseitigen Dokumenten oder Rechnungen mit Anhängen haben Kunden oft bereits ein fertiges PDF — und möchten dieses nicht neu aufbauen. Wir können bestehende PDFs mit einem strukturierten XML verbinden und daraus ein gültiges ZUGFeRD-Dokument erzeugen. Voraussetzung: Das XML muss alle steuerlich und gesetzlich relevanten Informationen vollständig enthalten, damit Mensch und Maschine denselben Rechnungsinhalt lesen.
ZUGFeRD-Profile: welches für welchen Anwendungsfall?
ZUGFeRD definiert fünf Konformitätsstufen. Die richtige Wahl hängt vom Empfänger und der Komplexität der Rechnung ab:
| Profil | EN 16931-konform | Typischer Einsatz |
|---|---|---|
| MINIMUM | ✕ | Interne EDI-Verarbeitung — nicht für die gesetzliche E-Rechnungspflicht geeignet |
| BASIC WL | ✕ | Sehr einfache Summenrechnungen — ebenfalls nicht EN 16931-konform |
| BASIC | Minimale EN-16931-Konformität — für unkomplexe B2B-Rechnungen ausreichend | |
| EN 16931Empfehlung | Empfehlung für KMU und die meisten B2B-Fälle | |
| EXTENDED | Industrie, Großhandel, komplexe Lieferketten |
MINIMUM und BASIC WL erfüllen die E-Rechnungspflicht nicht. Beide Profile sind keine vollständigen Umsetzungen der EN 16931: MINIMUM enthält nur steuerliche Pflichtfelder nach nationalem Recht, BASIC WL hat keine Positionsdaten. Für die gesetzliche Pflicht ab 2027/2028 sind ausschließlich BASIC, EN 16931 und EXTENDED geeignet.
Empfehlung für KMU und die meisten B2B-Fälle: ZUGFeRD EN 16931. Es deckt alle gesetzlichen Pflichtangaben nach § 14 UStG und EN 16931 vollständig ab. EXTENDED ist nur nötig, wenn der Empfänger es explizit anfordert — etwa weil sein ERP Zolltarifnummern oder Sub-Positionen verarbeitet.
Was ERP-Anbieter, DATEV und Buchhaltungssoftware empfehlen
Der Markt hat gesprochen — und er bevorzugt ZUGFeRD im B2B:
Entscheidungsmatrix: ZUGFeRD oder XRechnung?
| Ihr Szenario | Empfehlung | Grund |
|---|---|---|
| Rechnung an Bundesbehörde (B2G) | XRechnungPflicht | Gesetzliche Pflicht seit Nov. 2020 |
| Rechnung an Landesbehörde / Kommune | ZUGFeRD oder XRechnung | Immer mehr Länder/Kommunen akzeptieren ZUGFeRD EN 16931 — im Einzelfall prüfen |
| B2B ohne Formatvorgabe des Empfängers | ZUGFeRD EN 16931 | Breiteste Kompatibilität, kein Viewer nötig |
| Steuerberater / DATEV-Workflow | ZUGFeRD | DATEV unterstützt ZUGFeRD nativ, E-Mail-Versand bleibt möglich |
| DMS-Integration / Dokumentenablage | ZUGFeRD | PDF/A-3 ist ISO-normiertes Archivformat, kein Extraschritt nötig |
| E-Mail-Versand an Kunden | ZUGFeRD | Empfänger kann es mit jedem PDF-Reader öffnen |
| Empfänger fordert explizit XRechnung | XRechnung | Kundenvorgabe hat Vorrang |
| PEPPOL-Netzwerk | Beide möglich | PEPPOL transportiert beide Formate; sichererer Kanal als E-Mail |
| Konzern / großes ERP (SAP, Dynamics) | Abstimmen | Häufig EXTENDED oder XRechnung nach Einkaufsvorschrift |
ZUGFeRD 2.4 / Factur-X 1.08: Was sich seit Januar 2026 geändert hat
Am 4. Dezember 2025 veröffentlichten FeRD und das französische FNFE-MPE gemeinsam ZUGFeRD 2.4 / Factur-X 1.08, gültig seit 15. Januar 2026. Die wichtigsten Neuerungen:
Steuerkonforme Unterpositionen im EXTENDED-Profil: Erstmals können strukturierte Sub-Positionen MwSt.-konform abgebildet werden — relevant für Branchen mit komplexen Stücklisten.
UN/CEFACT CII D22B als technische Basis (vorher D16B) — vollständig rückwärtskompatibel: bestehende ZUGFeRD 2.x-Dateien bleiben gültig.
Aktualisierte Validierungsartefakte (XSD und Schematron) für alle fünf Profile.
Anpassungen berücksichtigen das BMF-Schreiben vom 15. Oktober 2025 zu umsatzsteuerlichen Anforderungen.
Was das für Sie bedeutet: Wenn Sie heute ZUGFeRD erzeugen, sollte Ihr System ZUGFeRD 2.4 / Factur-X 1.08 ausgeben. Ältere 2.x-Versionen sind weiterhin valide, aber der neue Standard bietet erweiterte Validierungssicherheit und ist BMF-konform für die E-Rechnungspflicht ab 2027.
Fazit: Die meisten Fälle sind eindeutig
Rechnen Sie an eine Bundesbehörde? → XRechnung, kein Spielraum.
Rechnen Sie B2B ohne explizite Empfänger-Vorgabe? → ZUGFeRD EN 16931, fast immer die richtige Wahl.
Empfänger fordert XRechnung? → XRechnung — und dann Sicherheitsmaßnahmen (PEPPOL, Stammdatenabgleich) vorsehen.
Steuerberater, DATEV, DMS, E-Mail? → ZUGFeRD, ohne Nachdenken.
Kein Format wählen und auf Papier-PDF warten? → Geht ab 2027/2028 nicht mehr für inländisches B2B.
Beide Formate aus einer API — fertig für 2027
rechnungsapi.de erzeugt XRechnung und ZUGFeRD (alle Profile bis EXTENDED) aus Ihren Rechnungsdaten — mit einem API-Aufruf, EN-16931-validiert, DKIM-signiert versendbar, EU-gehostet. Kostenloses Gespräch:
Verwandte Beiträge
ZUGFeRD BT-Felder: Komplette Referenz
Alle Business Terms für ZUGFeRD und XRechnung nach EN 16931 — Pflichtfelder, Datentypen, Kardinalität.
OZG-RE: XRechnung an den Bund
Leitweg-ID, Pflichtfelder und die drei Validierungsebenen bei Rechnungen an Bundesbehörden.
Sicherheit bei E-Rechnungen
XML, PEPPOL, EDI und ZUGFeRD — Sicherheitsrisiken und Lösungsansätze im Überblick.
Rechnung erzeugen und direkt versenden
XRechnung und ZUGFeRD aus einem API-Aufruf — DKIM-signiert per E-Mail zugestellt.
Rechtlicher Hinweis: Dieser Beitrag gibt den Stand vom 17.09.2026 wieder und ersetzt keine steuerliche oder rechtliche Beratung. Grundlagen: § 14 UStG, Wachstumschancengesetz, BMF-Schreiben vom 15.10.2025, EN 16931-1:2026, ZUGFeRD 2.4 / Factur-X 1.08, XRechnung 3.0.2.