ZUGFeRD und XRechnung sind die beiden deutschen Rechnungsformate, die die Norm EN 16931 erfüllen — und damit als E-Rechnung im Sinne des §14 UStG gelten. ZUGFeRD ist ein Hybrid: ein normal aussehendes PDF (PDF/A-3), in dem die Rechnungsdaten als maschinenlesbares XML eingebettet sind. XRechnung ist reines strukturiertes XML ohne jede visuelle Ebene. Beide transportieren dieselben Rechnungsdaten; sie unterscheiden sich in Verpackung, Zielgruppe und darin, wo sie verlangt werden. Dieser Ratgeber erklärt die Unterschiede, das Verhältnis zur EN 16931, die Validierung — und welches Format ein Shopify-Shop tatsächlich braucht. Für die meisten Händler lautet die Antwort: „beide, gewählt pro Rechnung".
Warum es diese zwei Formate gibt
Die E-Rechnungspflicht (unser kompletter Zeitplan 2027/2028) schreibt kein einzelnes Dateiformat vor. §14 UStG verlangt ein strukturiertes elektronisches Format, das der europäischen Norm EN 16931 entspricht — einem semantischen Datenmodell, das festlegt, was eine Rechnung enthalten muss (Verkäufer, Käufer, Positionen, USt-Aufschlüsselung, Summen) und wie jedes Element kodiert wird. Zwei deutsche Umsetzungen dieser Norm dominieren:
- XRechnung — der von der KoSIT (Koordinierungsstelle für IT-Standards der öffentlichen Verwaltung) gepflegte Standard. Entwickelt für Rechnungen an die öffentliche Hand, wo er nach der E-Rechnungsverordnung (ERechV) seit November 2020 Pflicht ist.
- ZUGFeRD — entwickelt vom FeRD (Forum elektronische Rechnung Deutschland), mit dem Ziel, dass eine Datei Mensch und Maschine zugleich bedient: ein PDF/A-3, das man öffnen und lesen kann, mit einer eingebetteten XML-Datei (CII-Syntax), die Buchhaltungssoftware automatisch ausliest.
Eine wichtige Feinheit: ZUGFeRD gilt nur ab Version 2.0.1 und nur in seinen EN-16931-konformen Profilen als E-Rechnung. Alte ZUGFeRD-1.0-Dateien und das abgespeckte MINIMUM-Profil tragen nicht den vollen EN-16931-Datensatz und erfüllen die Pflicht nicht. Wer sagt „ZUGFeRD zählt", meint ZUGFeRD 2.x im Profil EN 16931 oder höher.
Der Vergleich auf einen Blick
| ZUGFeRD 2.x | XRechnung 3.x | |
|---|---|---|
| Datei | Ein PDF/A-3 mit eingebettetem XML (hybrid) | Eine XML-Datei (UBL- oder UN/CEFACT-CII-Syntax) |
| Menschenlesbar? | Ja — öffnet sich wie jede PDF-Rechnung | Nicht direkt — braucht einen Viewer oder Software |
| Maschinenlesbar? | Ja — über das eingebettete XML | Ja — die Datei besteht aus nichts als Daten |
| Gepflegt von | FeRD (Forum elektronische Rechnung Deutschland) | KoSIT, im Auftrag der öffentlichen Verwaltung |
| Verlangt von | Niemandem speziell — akzeptiert, wo EN 16931 akzeptiert wird | Öffentlichen Auftraggebern (B2G, per ERechV); zunehmend auch von Großunternehmen |
| Typische Zielgruppe | B2B- und B2C-E-Commerce, KMU, alle, die eine lesbare Rechnung wollen | Behörden, Kommunen, öffentliche Einrichtungen, Konzern-Kreditorensysteme |
| Zusatzregeln | EN-16931-Kernregeln | EN 16931 plus deutsche BR-DE-Geschäftsregeln (z. B. Pflicht-Käuferreferenz BT-10, Ansprechpartnerdaten des Verkäufers) |
| Erfüllt die Pflicht 2027/2028? | Ja (Version ≥ 2.0.1, EN-16931-konformes Profil) | Ja |
| Validiert mit | veraPDF (PDF/A-3-Container) + EN-16931-Schematron für das XML | dem offiziellen KoSIT-Validator |
Das Verhältnis zur EN 16931
Stellen Sie sich EN 16931 als Grammatik und Vokabular vor — ZUGFeRD und XRechnung sind zwei Dokumente in dieser Sprache. Die Norm definiert rund 160 „Business Terms" (BT-1 Rechnungsnummer, BT-31 USt-IdNr. des Verkäufers, BT-118 USt-Kategorie usw.) plus Geschäftsregeln, die die Zahlen zum Aufgehen zwingen: Die Summe der Positionsbeträge muss dem Dokumentbetrag entsprechen, die USt-Aufschlüsselung muss zu den Steuersätzen passen — und Dutzende mehr.
Weil beide Formate dasselbe semantische Modell umsetzen, ist der Inhalt einer konformen ZUGFeRD-Rechnung und einer konformen XRechnung zur selben Bestellung praktisch identisch. Was sich unterscheidet:
- Syntax und Verpackung. ZUGFeRD bettet CII-XML in ein PDF/A-3 ein; die XRechnung ist eine nackte XML-Datei in UBL- oder CII-Syntax.
- Nationale Verschärfung. Die XRechnung legt deutsche Geschäftsregeln (BR-DE-*) auf die EN 16931 obendrauf. Die bekannteste: eine verpflichtende Leitweg-ID bzw. Käuferreferenz (BT-10), über die Behördensysteme die Rechnung routen, plus verpflichtende Ansprechpartnerdaten des Verkäufers (Name, Telefon, E-Mail). Eine Datei kann einwandfreies EN 16931 sein und trotzdem an der XRechnung-Validierung scheitern.
Versionen: ein bewegliches Ziel
Beide Standards leben. ZUGFeRD steht heute in der Generation 2.x; die Profile reichen von MINIMUM über BASIC bis EN 16931 und EXTENDED, und seit Version 2.1 ist ZUGFeRD technisch identisch mit dem französischen Standard Factur-X — dieselbe Datei gilt in beiden Ländern. Die XRechnung wird von der KoSIT regelmäßig fortgeschrieben; aktuell ist die Generation 3.x, und mit jeder neuen Fassung wird auch die Validator-Konfiguration ausgetauscht. Das hat eine unbequeme Konsequenz: Eine Rechnung, die letztes Jahr valide war, kann nach einem Versionswechsel gegen die aktuelle Prüfkonfiguration durchfallen. Wer selbst erzeugt, muss Versionsstände und Validator-Updates aktiv verfolgen; ein gutes Tool behandelt die Version als Konfiguration und zieht nach, ohne dass Sie es merken.
Validierung: der unterschätzte Teil
Eine E-Rechnung ist nicht „schon in Ordnung", wie man es von PDFs gewohnt ist. Empfangssysteme validieren eingehende Dateien und weisen fehlerhafte ab. Validierung vor dem Versand ist deshalb keine Kür — sie ist der Unterschied zwischen einer zugestellten und einer abgewiesenen Rechnung.
KoSIT-Validator (XRechnung)
Die KoSIT veröffentlicht die offizielle Validator-Konfiguration, die auch die Rechnungsportale der öffentlichen Hand einsetzen. Geprüft wird das XML gegen die EN-16931-Schematron-Regeln plus die deutschen BR-DE-Regeln. Was hier durchfällt, weist ein Rechnungsportal von Bund oder Ländern ab.
veraPDF (der PDF/A-3-Container von ZUGFeRD)
Eine ZUGFeRD-Datei muss zusätzlich ein gültiges PDF/A-3 sein — die ISO-genormte Archiv-Variante von PDF, die eingebettete Dateien erlaubt. Das prüft veraPDF, der Open-Source-Industrievalidator. Eine ZUGFeRD-Rechnung mit perfektem XML, deren PDF-Container gegen PDF/A-3 verstößt, ist trotzdem eine kaputte E-Rechnung.
Deshalb prüft Rechna jedes erzeugte Dokument vor der Auslieferung gegen den KoSIT-Validator und veraPDF — was einen Validator nicht besteht, wird nicht ausgeliefert. Wer Rechnungen anders erzeugt, sollte diese Validatoren selbst laufen lassen; die Systeme der Käufer tun es garantiert.
Welches Format braucht ein Shopify-Shop?
Verkauf an Endkunden (B2C)
Die E-Rechnungspflicht erfasst B2C nicht — ein strukturiertes Format ist nicht vorgeschrieben. ZUGFeRD ist trotzdem der kluge Standard: Ihr Kunde sieht ein vertrautes PDF, und jeder Geschäftskunde, der sich im B2C-Strom versteckt (das passiert ständig), bekommt automatisch ein konformes Dokument.
Verkauf an Unternehmen (B2B)
Ab 2027/2028 (je nach Umsatz — die Entscheidungstabelle steht im Zeitplan-Ratgeber) müssen inländische B2B-Rechnungen EN-16931-Dokumente sein. ZUGFeRD 2.x erfüllt das und hält die Rechnung für den Menschen auf der Gegenseite lesbar. Es ist das natürliche Format für E-Commerce-B2B.
Verkauf an die öffentliche Hand (B2G)
Schulen, Kommunen, öffentliche Einrichtungen: Hier ist die XRechnung Pflicht — schon seit 2020. Bestellt eine Landeseinrichtung in Ihrem Shop, kann ein ZUGFeRD-PDF abgewiesen werden. Sie brauchen eine echte XRechnung, inklusive der Käuferreferenz (BT-10), über die das System routet.
Große Geschäftskunden
Manche Konzern-Kreditorensysteme bevorzugen oder verlangen reine XRechnung, obwohl ZUGFeRD rechtlich genügen würde. Wer XRechnung auf Zuruf liefern kann, behält diese Kunden.
Die praktische Antwort für die meisten Shops lautet deshalb: kein Entweder-oder, sondern eine Wahl pro Rechnung — ZUGFeRD als Standard, XRechnung, wenn der Käufer es verlangt. Genau so arbeitet Rechna: Es wählt das passende Format je Rechnung automatisch, erzeugt ZUGFeRD 2.x oder XRechnung 3.x und legt das Ergebnis im vorgeschriebenen 8-Jahres-GoBD-Archiv ab (mehr dazu im Ratgeber zur GoBD-konformen Archivierung).
Verbreitete Irrtümer
- „Ein sauber aufgebautes PDF ist doch quasi ZUGFeRD." Nein. Ohne eingebettetes, EN-16931-konformes XML in einem gültigen PDF/A-3-Container ist es rechtlich nur ein PDF — eine „sonstige Rechnung" nach §14 UStG.
- „XRechnung ist das strengere Format, also nehme ich einfach immer XRechnung." Möglich, aber im E-Commerce kundenfeindlich: Endkunden und kleine Unternehmen können nacktes XML nicht öffnen. Das hybride ZUGFeRD existiert genau für dieses Publikum.
- „ZUGFeRD-1.0-Dateien reichen." Sie sind nicht EN-16931-konform und erfüllen die Pflicht nicht. Version 2.0.1 oder neuer, Profil EN 16931 oder höher.
- „Einmal erzeugt, ist die Datei konform." Das beweist nur die Validierung. Die Rechenregeln der EN 16931 (und die BR-DE-Regeln der XRechnung) lassen reale Rechnungen ständig durchfallen — besonders solche, die aus Bruttopreisen zurückgerechnet wurden. Genau das ist der Shopify-Fall.
Rechna ist Software, keine Steuerberatung. Welche Formatpflichten Sie treffen, hängt von Ihren Käufern ab — besprechen Sie die Details mit Ihrem Steuerberater.