E-Rechnung im B2B-Onlineshop: XRechnung und ZUGFeRD mit Shopware
XRechnung oder ZUGFeRD im B2B-Shop? Wir erklären die Unterschiede, Fristen und drei Wege, wie Shopware strukturierte E-Rechnungen erzeugt und versendet.

Eine PDF-Rechnung per E-Mail ist bequem lesbar, aber keine strukturierte E-Rechnung im Sinne von § 14 UStG. Seit dem 1. Januar 2025 müssen inländische Unternehmen E-Rechnungen empfangen können, ab 2028 wird die Ausstellung im inländischen B2B-Regelfall Pflicht — und Shopware 6 erzeugt ZUGFeRD-Dokumente seit Version 6.6.10.0 nativ. Für XRechnung braucht es je nach Zielprozess eine Erweiterung oder ERP-Integration.
Für den Empfänger bedeutet eine reine PDF weiterhin: Daten aus dem Dokument auslesen, prüfen und in das ERP übertragen. Eine E-Rechnung enthält die Rechnungsdaten dagegen in einem strukturierten Format, das Software direkt verarbeiten kann.
Für Betreiber eines B2B-Onlineshops ist das nicht nur eine Frage des Dateiformats. Die Rechnung muss aus korrekten Bestell-, Kunden-, Steuer- und Zahlungsdaten entstehen, zum passenden Geschäftsvorfall erzeugt werden, eine technische Prüfung bestehen und zuverlässig beim Empfänger ankommen.
Shopware kann diesen Prozess abbilden. Welche Lösung sinnvoll ist, hängt aber von Shopware-Version, B2B-Prozess, ERP, Zielformat und den Anforderungen der Geschäftskunden ab. Dieser Beitrag erklärt die Unterschiede zwischen XRechnung und ZUGFeRD, die deutschen Übergangsfristen und drei Wege zur Umsetzung mit Shopware 6.
Was ist eine E-Rechnung?
Eine E-Rechnung ist nicht einfach jede Rechnung, die digital verschickt wird. Eine PDF-Datei ist eine „sonstige Rechnung“, sofern sie nicht zusätzlich einen strukturierten Datenteil enthält. Eine E-Rechnung muss Rechnungsinformationen in einem strukturierten elektronischen Format übermitteln, das automatisiert verarbeitet werden kann.
In Deutschland orientieren sich zulässige Formate an der europäischen Norm EN 16931. XRechnung ist ein rein strukturiertes XML-Format. ZUGFeRD verbindet ein lesbares PDF mit eingebetteten strukturierten XML-Daten. Beide Datenteile gehören bei ZUGFeRD zu einer Datei.
Wichtig ist die Priorität der Daten: Bei einer hybriden Rechnung ist der strukturierte XML-Teil maßgeblich. Weicht der PDF-Bildteil davon ab, darf der Empfänger nicht einfach das PDF als Wahrheit behandeln. Deshalb müssen Rechnungserzeugung und Validierung gemeinsam geplant werden.
XRechnung und ZUGFeRD im Vergleich
Der Kernunterschied: XRechnung ist reines, maschinenorientiertes XML nach EN 16931 mit deutschen Geschäftsregeln; ZUGFeRD kombiniert ein lesbares PDF/A-3 mit eingebettetem XML in einer Datei. Beide sind als E-Rechnung zulässig — welcher Standard passt, entscheiden die Anforderungen der Empfänger und die ERP-Prozesse auf beiden Seiten.
| Format | Aufbau | Lesbarkeit | Typischer Einsatz |
|---|---|---|---|
| XRechnung | XML nach EN 16931 mit deutschen Geschäftsregeln | Nicht direkt für Menschen lesbar; Viewer nötig | ERP- und Behördenprozesse, automatisierte Eingangsverarbeitung |
| ZUGFeRD | PDF/A-3 plus eingebettetes XML | PDF direkt lesbar, XML maschinenlesbar | B2B-Rechnungen, bei denen Menschen und Systeme dieselbe Datei nutzen sollen |
XRechnung: strukturiert und maschinenorientiert
Eine XRechnung enthält keinen zusätzlichen PDF-Bildteil. Das ist für automatisierte Rechnungseingänge konsequent, verändert aber den Prozess für Menschen: Für die Darstellung braucht der Empfänger einen XML-Viewer oder ein ERP-System. Ein B2B-Kunde kann deshalb ausdrücklich XRechnung verlangen, obwohl ZUGFeRD technisch ebenfalls zulässig wäre.
Im B2B-Bereich braucht eine Rechnung grundsätzlich keine Leitweg-ID. Diese Adressierungsangabe gehört zum B2G-Prozess, also zur Rechnung an eine Behörde. Andere Käuferreferenzen, Bestellnummern oder Kundennummern können trotzdem fachlich erforderlich sein und müssen im Datenmodell vorhanden sein.
ZUGFeRD: PDF und XML in einer Datei
ZUGFeRD ist für viele B2B-Prozesse der pragmatische Einstieg: Der Empfänger kann die PDF wie gewohnt öffnen, während das ERP den XML-Teil verarbeitet. Für eine umsatzsteuerliche E-Rechnung muss das verwendete ZUGFeRD-Profil die Anforderungen der EN 16931 erfüllen. Die Profile MINIMUM und BASIC-WL reichen dafür nicht aus; in der Praxis wird häufig ein EN-16931-konformes Profil wie COMFORT beziehungsweise das entsprechende aktuelle Profil verwendet.
Welche Fristen gelten in Deutschland?
Die Fristen in Kürze: Seit dem 1. Januar 2025 müssen inländische Unternehmen E-Rechnungen empfangen können — dafür genügt grundsätzlich ein E-Mail-Postfach, und eine allgemeine Kleinunternehmer-Ausnahme gibt es nicht. Für die Ausstellung gelten Übergangsregeln: sonstige Rechnungen bleiben bis Ende 2026 zulässig, bei einem Vorjahresumsatz bis 800.000 Euro bis Ende 2027; ab 2028 ist die E-Rechnung im inländischen B2B-Regelfall verpflichtend. Rechtsgrundlage ist § 14 UStG; die Details erläutern die FAQ des Bundesfinanzministeriums und das BMF-Anwendungsschreiben.
Die Pflicht betrifft Umsätze zwischen inländischen Unternehmen; Ausnahmen und Sonderfälle, etwa Kleinbetragsrechnungen, müssen separat geprüft werden. Die Übergangsfrist ist kein Grund, die technische Vorbereitung aufzuschieben: Kunden, ERP und Buchhaltung benötigen Zeit für Tests und Prozessänderungen.
Die aktuelle Einordnung sollte immer mit Steuerberatung oder Rechtsberatung abgesichert werden. Dieser Beitrag beschreibt die technische Umsetzung, ersetzt keine steuerliche Prüfung.
Was kann Shopware 6 von Haus aus?
Shopware hat die E-Rechnung schrittweise in den Dokumentprozess integriert. Ab Shopware 6.6.10.0 unterstützt der Core laut Shopware ZUGFeRD-Dokumente. Die strukturierten Daten können als separate XML-Datei ausgegeben oder direkt in das PDF eingebettet werden. Seit Shopware 6.7.9.0 lassen sich zusätzliche Dokumenttypen in ZUGFeRD erzeugen, zum Beispiel Gutschriften oder Stornodokumente.
Die Grundlage bleiben die normalen Shopware-Dokumente: Rechnung, Stornorechnung, Gutschrift und Lieferschein. In den Dokumenteinstellungen von Shopware werden unter anderem Layout, Geschäftsdaten und die anzuzeigenden Bestellinformationen konfiguriert. Die ZUGFeRD-Varianten greifen auf diese Daten zurück.
Das bedeutet aber nicht, dass jede Installation sofort jede gewünschte XRechnung erzeugt. Der native Shopware-Dokumentprozess deckt insbesondere ZUGFeRD ab. Für XRechnung kommen je nach Zielprozess eine Erweiterung, ein ERP-System oder eine individuelle Integration hinzu. Entscheidend ist nicht der Name eines Plugins, sondern ob es die benötigte Shopware-Version, das gewünschte Profil, Korrektur- und Stornofälle sowie die eigenen Steuer- und B2B-Daten korrekt abbildet.
Drei Umsetzungswege für XRechnung und ZUGFeRD
Drei Wege führen zur E-Rechnung mit Shopware: der Core-Weg für ZUGFeRD (ab 6.6.10.0), eine Erweiterung für XRechnung und gemischte Anforderungen oder eine ERP- beziehungsweise Individualintegration, wenn das ERP das führende Rechnungssystem ist. Welcher Weg passt, hängt von Shopware-Version, Zielformat und Systemlandschaft ab.
1. ZUGFeRD mit dem Shopware-Core
Für einen B2B-Shop mit aktueller Shopware-6-Version ist der Core-Weg der kleinste Einstieg, wenn ZUGFeRD genügt. Die Rechnung wird wie bisher aus dem Bestellprozess erzeugt; zusätzlich wird die passende ZUGFeRD-Variante erstellt und entweder eingebettet oder als XML bereitgestellt.
Vor dem produktiven Einsatz müssen insbesondere folgende Daten geprüft werden:
- vollständige Verkäufer- und Käuferadresse,
- Umsatzsteuer-Identifikationsnummer und Steuerkategorie,
- Rechnungsnummer und Rechnungsdatum,
- Positionen, Mengen, Preise und Steuerbeträge,
- Zahlungsbedingungen, Zahlungsart und Fälligkeit,
- Bestellnummer oder andere Käuferreferenz,
- Versandkosten, Rabatte, Gutschriften und Stornierungen.
Ein hübsches PDF beweist noch keine gültige E-Rechnung. Das XML muss gegen die relevanten Geschäftsregeln validiert und mit realen Geschäftsfällen getestet werden.
2. Erweiterung für XRechnung und gemischte Anforderungen
Wenn Kunden XRechnung ausdrücklich verlangen oder zusätzliche Profile, Dokumenttypen und automatische Versandregeln benötigt werden, ist eine Shopware-Erweiterung oft der passende Weg. Im Shopware Extension Store gibt es Lösungen für XRechnung und ZUGFeRD. Sie ergänzen den Dokumentprozess, erzeugen XML und können die Ausgabe je nach Kunde, Land, Steuerfall oder Bestellstatus steuern.
Die Auswahl ist eine Architekturentscheidung, keine reine Installationsfrage. Zu prüfen sind unter anderem:
- unterstützte Shopware-Version und Updatepfad,
- XRechnung- und ZUGFeRD-Profile,
- automatische oder manuelle Dokumenterzeugung,
- PDF/XML-E-Mailversand und Download im Kundenkonto,
- Gutschriften, Teilstornos und Korrekturrechnungen,
- Käuferreferenzen, Leitweg-ID-Felder und internationale Steuerfälle,
- Validierung, Logging und Wiederholbarkeit bei Versandfehlern.
Eine Erweiterung sollte zunächst in einer Staging-Umgebung mit anonymisierten oder synthetischen Bestellungen geprüft werden. Das schützt nicht nur vor Formatfehlern, sondern auch vor Seiteneffekten in Nummernkreisen, Bestellstatus und E-Mail-Automatisierung.
3. ERP- oder Individualintegration
In komplexen B2B-Shops ist das ERP häufig das führende System für Rechnungen. Shopware überträgt dann die Bestellung, das ERP erzeugt und verbucht die Rechnung und ein Versanddienst oder das ERP liefert XRechnung beziehungsweise ZUGFeRD aus. Shopware stellt die Rechnung anschließend im Kundenkonto bereit oder verknüpft sie mit dem Auftrag.
Diese Architektur vermeidet doppelte Rechnungslogik. Sie braucht aber eine saubere Zustandsmaschine: Was passiert bei einer abgebrochenen Übertragung, einer Korrektur, einem Teilstorno oder einer verspäteten Rückmeldung? Für solche Fälle sind eine eindeutige externe Rechnungs-ID, Idempotenz, Fehlerprotokoll und ein manueller Wiederanlauf wichtiger als ein weiterer Button im Admin.
Unsere Shopware-Entwicklung umfasst solche Schnittstellen und individuellen Dokumentprozesse. Bei einem bestehenden Shop beginnt die Arbeit sinnvollerweise mit einem System-Audit, nicht mit der Installation eines Plugins.
Der technische Ablauf im B2B-Shop
Unabhängig vom gewählten Weg folgt ein belastbarer Ablauf sieben Schritten: vom Erkennen des Geschäftskunden über die Erzeugung von Rechnung und XML aus denselben Quelldaten und die Validierung gegen EN 16931 bis zu Versand, revisionssicherem Protokoll und der Verknüpfung im Kundenkonto. Vereinfacht:
- Der Shop erkennt den Geschäftskunden und übernimmt Kunden-, Steuer- und Referenzdaten.
- Die Bestellung wird in Shopware oder im ERP geprüft und verbucht.
- Das führende System erzeugt Rechnung und XML aus denselben Quelldaten.
- Die Datei wird gegen EN 16931 und das gewählte Profil validiert.
- XRechnung oder ZUGFeRD wird über den vereinbarten Kanal versendet.
- Status, Dokument-ID und Fehlermeldungen werden revisionssicher protokolliert.
- Rechnung, Gutschrift oder Storno wird im Kundenkonto und gegebenenfalls im ERP verknüpft.
Ein PDF sollte nicht nachträglich in XML „umgewandelt“ werden, wenn die ursprünglichen Positions- und Steuerdaten noch verfügbar sind. Die strukturierte Rechnung sollte direkt aus dem fachlichen Datenmodell entstehen.
Typische Fehler bei der Einführung
Fünf Fehler dominieren bei der Einführung: PDF mit XML verwechseln, nur den Standardfall testen, Empfängeranforderungen ignorieren, erst nach dem Versand validieren und Shopware-Version samt Erweiterungen nicht gemeinsam betrachten. Jeder davon fällt erst im Echtbetrieb auf — und dann teuer.
PDF mit XML verwechseln
Eine PDF per E-Mail ist keine E-Rechnung. Auch ein PDF mit einem QR-Code ist nicht automatisch ein EN-16931-konformes Rechnungsformat.
Nur den Standardfall testen
Normalbesteuerte Ware mit einer Lieferadresse reicht nicht. Tests müssen auch Rabatte, Versandkosten, mehrere Steuersätze, steuerfreie Positionen, innergemeinschaftliche Lieferungen, Gutschriften und Stornos abdecken.
Empfängeranforderungen ignorieren
Ein Kunde kann ZUGFeRD, XRechnung, bestimmte Profile oder eine eigene Referenzlogik verlangen. Vor dem Rollout sollte deshalb ein kleines Empfängerprofil vorliegen: Format, Profil, Versandkanal, Pflichtfelder und Ansprechpartner für Fehler.
Validierung erst nach dem Versand
Ein Empfänger-ERP ist kein Testsystem. Die Validierung muss vor Versand und idealerweise bereits in der automatisierten Dokumenterzeugung erfolgen.
Shopware-Version und Erweiterungen nicht gemeinsam betrachten
E-Rechnung berührt Dokumente, Steuern, Bestellungen, Statusflows, E-Mail, Kundenkonto und oft das ERP. Updates an einer Stelle können das Ergebnis an anderer Stelle verändern. Shopware Support und Wartung mit Staging-Tests und kontrolliertem Rollout reduziert dieses Risiko.
Ein sinnvoller Einführungsplan
Der Einführungsplan folgt fünf Schritten: Empfängeranforderungen sammeln, das führende Rechnungssystem festlegen, Datenlücken schließen, Formate und Integration testen sowie Versand und Archivierung beobachten. Die Reihenfolge ist bewusst — wer mit dem Plugin statt mit den Empfängern beginnt, testet am Bedarf vorbei.
1. Anforderungen der Empfänger sammeln
Welche Kunden benötigen XRechnung? Reicht ZUGFeRD? Welche Profile, Referenzen und Versandwege werden verlangt?
2. Führendes Rechnungssystem festlegen
Entsteht die Rechnung in Shopware, im ERP oder in einem spezialisierten E-Rechnungsdienst? Zwei Systeme dürfen nicht unabhängig voneinander Rechnungsnummern und Steuerdaten erzeugen.
3. Datenlücken schließen
Prüfen Sie Firmenname, Adressen, USt-IdNr., Kundennummer, Bestellreferenz, Steuerlogik, Zahlungsbedingungen und Artikelstammdaten. Fehlende Daten sind meist das eigentliche E-Rechnungsprojekt.
4. Format und Integration testen
Erzeugen Sie beide Formate, validieren Sie sie und lassen Sie Testdateien von den wichtigsten Empfängern oder deren ERP prüfen. Testen Sie auch Korrektur- und Stornofälle.
5. Versand und Archivierung beobachten
Protokollieren Sie Erstellung, Validierung, Versand, Zustellung, erneute Zustellung und Fehler. Eine E-Rechnung ist erst dann ein stabiler Prozess, wenn auch der Ausnahmefall beherrscht wird.
Fazit: Shopware kann E-Rechnung – die Architektur entscheidet
Shopware 6 bietet für ZUGFeRD inzwischen eine native Grundlage. XRechnung, komplexe Empfängerprofile und ERP-geführte Rechnungen benötigen je nach Setup eine Erweiterung oder eine individuelle Integration. In allen Fällen gilt: Die technische Datei ist nur der sichtbare Teil. Entscheidend sind korrekte B2B-Stammdaten, steuerlich konsistente Geschäftsfälle, Validierung, Fehlerbehandlung und ein klarer Verantwortlicher.
Mit unserem F.O.C.U.S.-System beginnen wir bei den Facts: Welche Daten und Systeme sind wirklich vorhanden? Danach definieren wir das Ziel, machen Integrationsgrenzen sichtbar, setzen den passenden Weg um und betreiben ihn kontrolliert weiter. So wird E-Rechnung kein isoliertes Plugin, sondern ein belastbarer Teil des B2B-Commerce.
Offizielle Quellen
Reden wir über dein System.
Kein Pitch-Deck. Ein Gespräch mit denen, die auch bauen.
