E-Rechnungspflicht ab 1. Januar 2027: Was Shopware-B2B-Shops jetzt prüfen müssen

1. Was ab 2027 gilt — und für wen

Der Rahmen ist kurz erklärt: Seit dem 1. Januar 2025 müssen inländische Unternehmen E-Rechnungen empfangen können. Ausstellen müssen sie ab 1. Januar 2027, wenn der Gesamtumsatz im Vorjahr über 800.000 € lag, für 2027 zählt also das Jahr 2026. Wer darunter bleibt, hat eine Übergangsfrist bis 31. Dezember 2027; ab 2028 gilt die Pflicht grundsätzlich für alle. Eine Verschiebung auf 2028 wird von Teilen des Handwerks gefordert, beschlossen war sie laut diesem Überblick Anfang September nicht. Plane mit dem 1. Januar.

Betroffen ist nur der inländische B2B-Bereich. Rechnungen an Privatkunden sind ausgenommen, ebenso Kleinbetragsrechnungen bis 250 €, und Kleinunternehmer nach § 19 UStG müssen zwar empfangen, aber nicht ausstellen. Bei Lieferungen ins Ausland oder an ausländische Besteller musst du den Einzelfall prüfen. Das ist keine Rechtsberatung; für die Umsatzgrenze und Grenzfälle gehört dein Steuerberater ins Boot.

2. Was als E-Rechnung zählt — und was nicht mehr

Eine E-Rechnung ist ein strukturierter, maschinenlesbarer Datensatz nach EN 16931. In der Praxis sind das zwei Formate: XRechnung ist reines XML, ZUGFeRD (ab Version 2.0.1) ein Hybrid aus PDF/A-3 mit eingebettetem XML. Ein normales PDF ist seit 2025 nur noch eine „sonstige Rechnung“ und genügt ab der jeweiligen Frist nicht mehr. Bei ZUGFeRD ist das Profil entscheidend: MINIMUM und BASIC-WL erfüllen die umsatzsteuerlichen Anforderungen nicht.

Der Punkt, der in Shops gern untergeht: die Archivierung. E-Rechnungen sind acht Jahre aufzubewahren, und zwar im Originalformat, unverändert und maschinenlesbar. Ein Ausdruck oder eine XML-Ansicht ersetzt das Original nicht. Bei ZUGFeRD hat der strukturierte Teil Vorrang. Wenn dein Shop heute Rechnungs-PDFs nur on the fly erzeugt und nicht dauerhaft speichert, ist das ein Problem — unabhängig vom Format.

3. Was Shopware im Core mitbringt

Anders als die Faustregel „Shopware macht nur PDF“ erzeugt der Core inzwischen ZUGFeRD-Dokumente: Im Repository liegen ZugferdDocument und ZugferdRenderer unter src/Core/Checkout/Document, wie man etwa am offenen Pull Request #21499 sieht. Eine Code-Analyse von Pixup Media (Stand September, ohne Validator-Lauf mit echten Bestellungen) beschreibt, was dabei herauskommt: festes XRechnung-3-Profil, nicht konfigurierbar; Dokumenttypen für Rechnung, Storno und Gutschrift, jeweils als XML und eingebettet im PDF; Rechnungsnummer aus einem Nummernkreis pro Verkaufskanal.

Behandle diese Angaben als Hinweis, nicht als Garantie: Ich habe den Code nicht selbst gegen einen Validator gefahren, und die Analyse sagt ausdrücklich, dass sie das auch nicht getan hat. Dein erstes Projekt für diese Woche ist deshalb kein Plugin, sondern ein Test: eine echte Bestellung mit Staffelpreis, Rabatt und Versand durchschicken und das Ergebnis in einen XRechnung-Validator geben.

4. Wo die Lücken sitzen

Nach der genannten Analyse und dem Pull Request sind das die Stellen, an denen B2B-Shops typischerweise nacharbeiten müssen:

• Buyer Reference. Der Core trägt hier die Bestellnummer ein. Eine Leitweg-ID oder eine kundenspezifische Referenz, die Behörden und viele Konzerne verlangen, setzt er nicht. Sie muss über ein eigenes Ereignis oder ein Custom Field am Kunden ergänzt werden.
• Zahlungsmittel. Zugeordnet werden laut Analyse nur Barzahlung, Rechnung und Vorkasse. Für Lastschrift und Drittanbieter-Zahlarten fehlt der Eintrag, und der bezahlte Betrag wird nur bei Transaktionsstatus „paid“ übernommen.
• Einheiten. Bisher wird für jede Position H87 (Stück) gesendet. Der Fix mit dem echten UN/ECE-Code der Produkteinheit ist als Pull Request offen und mit dem Label 6.8 versehen, also nichts, worauf du bis Januar warten solltest. Wer Meter, Kilogramm oder Paletten verkauft, braucht jetzt eine eigene Lösung.
• Gutschriften und Storno. Der Bezug auf die Ursprungsrechnung ist laut Analyse vorgesehen; teste ihn mit Teilgutschriften, denn dort scheitern Validatoren am häufigsten.

5. Core ausbauen oder Erweiterung nehmen

Es gibt am Markt mehrere Erweiterungen. Ein Beispiel ist die Factur-X-Erweiterung von IWV: Profile Extended und XRechnung, Dokumenttypen Rechnung, Storno und Gutschrift, automatische Erzeugung beim Statuswechsel, kompatibel bis 6.7.15.1, zum Zeitpunkt der Recherche 49 € netto im Monat bzw. 390 € im Jahr. Das ist ein Datenpunkt, keine Empfehlung; ich habe die Erweiterung nicht im Projekt getestet.

Meine Faustregel: Reicht der Core in deinem Validator-Test, brauchst du nichts Zusätzliches, höchstens einen kleinen Subscriber für die Buyer Reference. Scheitert der Test an mehreren Punkten gleichzeitig, rechnet sich eine Erweiterung schnell gegen die Entwicklungsstunden. Wichtig ist, dass sie ein Update überlebt: Nimm nichts, das den Dokument-Renderer überschreibt, wenn ein Event oder Decorator reicht.

6. Checkliste für die nächsten elf Wochen

• Betroffenheit klären: Vorjahresumsatz 2026, Anteil B2B im Inland, mit dem Steuerberater abgestimmt.
• Ist-Stand testen: Testbestellung durchschicken, XML in einen Validator geben, Fehler dokumentieren.
• Pflichtdaten ergänzen: Leitweg-ID oder Kundenreferenz, Zahlungsmittel, Einheiten, USt-IDs in den Firmenkonten.
• ERP und Buchhaltung einbinden: Wer Rechnungen im ERP erzeugt, klärt, welches System künftig die E-Rechnung stellt. Zwei Quellen für dieselbe Rechnungsnummer sind der teuerste Fehler.
• Archiv aufsetzen: Original-XML bzw. Hybrid-PDF acht Jahre unverändert ablegen, auffindbar je Bestellung.
• Versand testen: Mailanhang, Kundenportal-Download und Verhalten bei Gutschriften mit Echtdaten prüfen, nicht erst im Januar.

Und noch ein Gedanke zum Zeitplan: Die Weihnachtswochen sind für viele B2B-Shops Hochsaison. Ein Release, das Rechnungsdokumente ändert, gehört vor Mitte Dezember auf Produktion, nicht in die Woche vor Silvester.