ZUGFeRD Stornorechnungen & Gutschriften: Storno-Dokumente 2026

Seit dem 1. Januar 2025 besteht eine uneingeschränkte Empfangspflicht für E-Rechnungen nach EN 16931 im deutschen B2B (BMF 15.10.2024). Wer Rechnungen im Online-Shop erstellt, muss dieselbe Sorgfalt auf Stornorechnungen, Gutschriften und Korrekturen anwenden — denn auch diese Dokumente unterliegen der neuen Pflicht (§ 14 Abs 2 Satz 5 UStG). Der ITK-Markt wächst 2026 laut Bitkom auf 245,1 Mrd. EUR (+4,4 Prozent), und ZUGFeRD 2.3 wurde am 18.09.2024 EN-16931-konform veröffentlicht (FeRD/AWV). In diesem Beitrag zeigen wir, wie Sie die drei BT-3 Invoice Type Codes 380, 381 und 384 im Shopware-Workflow sauber trennen und GoBD-konform umsetzen.

E-Rechnungs-Fristen im Überblick

Mit dem Wachstumschancengesetz ist § 14 UStG seit dem 31.12.2024 aktiv (BMF). Seitdem gilt die Empfangspflicht uneingeschränkt: Jeder deutsche B2B-Unternehmer muss strukturierte E-Rechnungen verarbeiten können. Als gültige Formate nennt das BMF-Schreiben ausdrücklich XRechnung und ZUGFeRD ab Version 2.0.1 (BMF/KoSIT). Für die Versandseite hat der Gesetzgeber gestaffelte Übergänge definiert — die folgende Tabelle fasst zusammen, welcher Stichtag für wen gilt.

Für Shopbetreiber ist der Kalender damit klar: Wer bereits heute B2B verkauft, muss in der Lage sein, eingehende ZUGFeRD- oder XRechnung-Dokumente elektronisch zu verarbeiten — das betrifft typischerweise auch Gutschrifts- und Storno-Belege von Lieferanten. Die Versandseite folgt gestaffelt, ist aber nicht optional: Ab 2028 gilt die Versandpflicht ausnahmslos für alle B2B-Umsätze (BMF). In der Praxis bedeutet das, dass jeder Shopware-Shop spätestens 2027 eine vollständige ZUGFeRD-Versandpipeline haben sollte — inklusive sauberer Behandlung aller Storno- und Korrekturvorgänge, weil diese häufig den Ernstfall einer Rechnungsübertragung bilden.

Wichtig für den E-Commerce: Die Empfangs- und Versandpflicht erstreckt sich nach § 14 Abs 2 Satz 5 UStG ausdrücklich auch auf Gutschriften — also auf alle Rechnungskorrekturen, die eine ursprüngliche Leistungsabrechnung rückgängig machen oder anpassen (BMF). Wer diese Dokumente weiterhin als PDF oder Papier versendet, verstößt gegen die neue Formatpflicht. Mehr zur grundlegenden Umsetzung haben wir im Beitrag E-Rechnungspflicht 2026 für Online-Shops zusammengefasst.

Storno, Gutschrift, Korrektur: Drei Dokumente, drei Codes

Die EN 16931 kodiert den Rechnungstyp über das Feld BT-3 (Invoice Type Code). Drei Codes sind für den Shop-Alltag relevant: 380 für die reguläre Rechnung, 381 für Gutschrift oder Storno und 384 für die Korrekturrechnung (EN 16931/KoSIT). Die Abgrenzung ist nicht nur formal — sie bestimmt, wie das Dokument in Buchhaltungssoftware und DATEV-Schnittstelle verarbeitet wird. Fehler an dieser Stelle führen zu Buchungsproblemen beim Empfänger und zu Rückfragen der Finanzverwaltung.

BT-3 Invoice Type Code: Was wann verwenden?

Code 381 ist der Klassiker für Stornos und kaufmännische Gutschriften: eine bereits ausgestellte Rechnung wird vollständig rückgängig gemacht, etwa nach einer Retoure oder einem Widerruf. Laut E-Rechnung-Bund FAQ gilt dabei eine für viele Shopbetreiber überraschende Regel: Die Beträge sind positiv anzugeben — das Minuszeichen wird nicht in die Werte geschrieben, sondern durch den Code 381 impliziert (E-Rechnung-Bund FAQ). Hier ein minimales Beispiel im ZUGFeRD-BASIC-Profil.

In vielen Shopware-Installationen ist dieser Punkt die häufigste Quelle von Validierungsfehlern: Teams, die aus der klassischen Rechnungskorrektur kommen, schreiben reflexartig negative Werte in das XML und wundern sich, dass Empfänger-Systeme die Datei als ungültig ablehnen. Der saubere Weg ist eine Template-Logik, die den Beleg-Typ zentral setzt, die Beträge vorzeichenfrei übernimmt und alle Kopf- sowie Positionssummen konsistent hält. Ein nicht konsistentes Summary-Feld (etwa wenn LineTotalAmount und GrandTotalAmount nicht zusammenpassen) schlägt in der Schematron-Prüfung genauso zuverlässig fehl wie ein fehlender Steuer-Aufbruch (KoSIT).

<rsm:CrossIndustryInvoice xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100">
  <rsm:ExchangedDocument>
    <ram:ID>RE-2026-001-S</ram:ID>
    <ram:TypeCode>381</ram:TypeCode>
    <ram:IssueDateTime>
      <udt:DateTimeString format="102">20260422</udt:DateTimeString>
    </ram:IssueDateTime>
  </rsm:ExchangedDocument>
  <rsm:SupplyChainTradeTransaction>
    <ram:ApplicableHeaderTradeSettlement>
      <ram:SpecifiedTradeSettlementHeaderMonetarySummation>
        <ram:LineTotalAmount>1000.00</ram:LineTotalAmount>
        <ram:TaxBasisTotalAmount>1000.00</ram:TaxBasisTotalAmount>
        <ram:GrandTotalAmount>1190.00</ram:GrandTotalAmount>
      </ram:SpecifiedTradeSettlementHeaderMonetarySummation>
    </ram:ApplicableHeaderTradeSettlement>
  </rsm:SupplyChainTradeTransaction>
</rsm:CrossIndustryInvoice>

Code 384 (Corrected Invoice) wird immer dann verwendet, wenn nicht die komplette Rechnung storniert, sondern nur einzelne Positionen oder Werte angepasst werden — etwa ein falscher Steuersatz oder eine versehentlich falsche Menge. Anders als Code 381 erfordert 384 zwingend eine Vorrechnungs-Referenz (KoSIT). Dazu mehr im nächsten Abschnitt.

Die saubere Trennung zwischen 381 und 384 zahlt sich spätestens in der Buchhaltung aus: Ein Storno mit Code 381 wird in vielen ERP-Systemen als eigener Buchungssatz erfasst, der die ursprüngliche Forderung auflöst. Eine Korrektur mit Code 384 wird dagegen als Anpassungssatz behandelt, der die bestehende Forderung verändert — inklusive Umsatzsteuer-Delta. Wer in einem B2B-Kontext Teilrückläufer oder Mengenanpassungen abbildet, sollte daher nicht reflexartig zu 381 greifen: Code 384 ist in der Regel die kaufmännisch und steuerlich saubere Wahl, weil er die Historie des ursprünglichen Belegs transparent weiterführt.

BG-3 Preceding Invoice Reference: Pflichtfelder

Korrekturrechnungen mit Code 384 müssen die ursprüngliche Rechnung eindeutig referenzieren. Dafür nutzt die EN 16931 die Business Group BG-3 (Preceding Invoice Reference) mit dem Pflichtfeld BT-25 (Preceding Invoice Reference) für die Nummer und dem optionalen BT-26 (Preceding Invoice Issue Date) für das Datum (KoSIT). Ist die Rechnungsnummer des Vorgängers nicht eindeutig, wird BT-26 durch die KoSIT-Validierung zur De-facto-Pflicht.

<rsm:ExchangedDocument>
  <ram:ID>RE-2026-001-K</ram:ID>
  <ram:TypeCode>384</ram:TypeCode>
  <ram:IssueDateTime>
    <udt:DateTimeString format="102">20260423</udt:DateTimeString>
  </ram:IssueDateTime>
</rsm:ExchangedDocument>
<!-- BG-3: Preceding Invoice Reference -->
<ram:ApplicableHeaderTradeSettlement>
  <ram:InvoiceReferencedDocument>
    <ram:IssuerAssignedID>RE-2026-001</ram:IssuerAssignedID>
    <ram:FormattedIssueDateTime>
      <qdt:DateTimeString format="102">20260315</qdt:DateTimeString>
    </ram:FormattedIssueDateTime>
  </ram:InvoiceReferencedDocument>
</ram:ApplicableHeaderTradeSettlement>

• BT-25 (Invoice Reference) — Nummer der Vorrechnung, Pflichtfeld bei Code 384 (KoSIT)
• BT-26 (Preceding Invoice Issue Date) — Datum der Vorrechnung, faktisch Pflicht bei nicht eindeutigen Nummernkreisen (KoSIT)
• BG-3 umhüllt als Business Group beide Felder und referenziert das vorangegangene Dokument eindeutig
• ZUGFeRD 2.3 im Profil EXTENDED erlaubt zusätzlich eine definierte Rundungs-Toleranz für Korrekturbeträge (FeRD)
• ZUGFeRD 2.3 basiert technisch auf UN/CEFACT CII SCRDM D22B und ist rückwärtskompatibel zu D16B (FeRD)

GoBD-konforme Storno-Workflows

Die Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern (GoBD) formulieren eine klare Regel: Sobald eine Rechnung an den Empfänger versendet wurde, darf sie nicht mehr editiert werden. Korrekturen dürfen ausschließlich über eine Storno-Rechnung und eine Neuausstellung erfolgen (GoBD). Das gilt unabhängig vom Format — auch ein lokal im Shopware-Shop erzeugtes PDF, das bereits per E-Mail an den Kunden ging, ist aus GoBD-Sicht fixiert. Im Kombination mit ZUGFeRD heißt das: Storno und Korrektur sind eigenständige Dokumente mit eigener Nummer und eigenem BT-3 Code.

Ein gut dokumentierter Storno-Workflow bildet diese Anforderung technisch ab, indem die ursprüngliche Rechnung nach Versand unveränderlich in der Datenbank markiert wird. Jeder Zugriff, der das Dokument modifizieren würde, erzeugt stattdessen einen neuen Beleg — entweder ein Storno (381) oder eine Korrektur (384). Shopware 6 unterstützt dieses Muster über den Dokumenten-Service; für revisionssichere Archivierung empfiehlt sich zusätzlich eine Signatur oder ein Hash-Wert pro Dokument, der in den Audit-Log geschrieben wird. So bleibt jederzeit nachvollziehbar, wer wann welchen Beleg erzeugt hat — eine Anforderung, die in GoBD-Prüfungen regelmäßig explizit angefragt wird (GoBD).

Besonders in E-Commerce-Umgebungen mit hohem Retourenaufkommen zahlt sich eine klare Event-Architektur aus: Ein Retouren-Event im Shop löst deterministisch eine Storno- oder Korrekturrechnung aus, der CRM-Datensatz wird synchron aktualisiert, und die Buchhaltung erhält das ZUGFeRD-Dokument ohne manuelle Zwischenschritte. Das reduziert nicht nur Fehler, sondern schließt eine typische GoBD-Lücke — das manuelle Nacharbeiten von Belegen über Tabellen oder Notizen, das im Prüffall regelmäßig für Diskussionen sorgt.

Shopware 6: Storno-Dokumente erstellen

Shopware 6 unterstützt in der Community Edition die Dokumenttypen Rechnung, Storno, Gutschrift und Lieferschein und kann diese mit den BT-3 Codes 380, 381 und 384 exportieren (Shopware). Die Storno-Erstellung erfolgt in der Administration direkt aus der Bestellung heraus; alternativ lassen sich Dokumente per CLI oder API neu generieren, ohne den ursprünglichen Beleg zu überschreiben. In einem älteren Community-Forum-Thread wird ein ausgegrauter Storno-Button in bestimmten Bestell-Zuständen als Limitation diskutiert (Shopware Community Forum) — ein Punkt, den wir in Kundenprojekten regelmäßig durch eine saubere Status-Choreographie adressieren.

Im produktiven Einsatz verknüpfen wir die Dokument-Erzeugung mit Workflow-Events: Sobald im Shop eine Retoure genehmigt wird (siehe unser Beitrag Retourenmanagement im E-Commerce sowie der Widerrufsbutton-Artikel), löst das System automatisch Storno und ggf. Korrekturrechnung aus — inklusive ZUGFeRD-Export in die Buchhaltung.

Ein weiterer Praxis-Tipp betrifft das Nummernkreis-Design: Stornos (381) und Korrekturen (384) sollten eigene Suffixe oder eigene Nummernkreise bekommen — etwa RE-2026-001 für die Rechnung, RE-2026-001-S für den Storno und RE-2026-001-K für die Korrektur. So sind alle drei Dokumente auf einen Blick zusammengehörig, gleichzeitig aber über eindeutige IDs referenzierbar. In der Shopware-Administration lässt sich dieses Schema über Dokument-Nummernkreise sauber konfigurieren. Wichtig ist nur, dass die Rechnungsnummer des Ursprungsbelegs nicht wiederverwendet wird — das ist in der Regel nicht nur GoBD-kritisch, sondern bricht in Buchhaltungssystemen die Verknüpfung zwischen Originalbeleg und Korrekturdokument auf Dateiebene.

Umgangssprachliche Gutschrift vs. § 14 UStG Gutschrift

Für die ZUGFeRD-Praxis bedeutet das: Eine umgangssprachliche Gutschrift (z. B. Erstattung nach Retoure) wird technisch als Storno mit BT-3 = 381 oder als Korrektur mit BT-3 = 384 abgebildet — nicht als gesonderter Beleg im Sinne § 14 Abs 2 UStG. Wer in der PDF-Schicht das Wort Gutschrift drucken möchte, sollte diese Unterscheidung im Template klar kennzeichnen, um keine Verwechslung mit der steuerlichen Gutschrift zu erzeugen.

In unseren Shopware-Projekten empfehlen wir eine Template-Variable, die je nach BT-3 Code eine andere Überschrift ausgibt — etwa Stornorechnung für 381 mit Bezug auf die Ursprungsrechnung und Korrekturrechnung für 384 mit expliziter Nennung der geänderten Positionen. Das Wort Gutschrift bleibt dann echten § 14-UStG-Konstellationen vorbehalten. Für den Empfänger ist das nicht nur freundlicher zu lesen, sondern verhindert auch, dass die Rechnung versehentlich als gesonderter Abrechnungsbeleg im Sinne § 14c UStG interpretiert wird — ein Risiko, das die Finanzverwaltung bei unsauberer Beleg-Bezeichnung prüfen kann (BMF).

Typische Fehler bei Korrekturrechnungen

• Minuszeichen in Code 381 — Beträge müssen positiv sein; das Minus wird durch den Code impliziert (E-Rechnung-Bund FAQ)
• Vergessene BG-3 Referenz bei Code 384 — ohne BT-25 scheitert die KoSIT-Validierung (KoSIT)
• Gleiche Rechnungsnummer wie Original — Storno braucht eine eigene Nummer, sonst brechen Buchhaltungssysteme die Verknüpfung
• Editierung der Originalrechnung im Backend — verstößt gegen GoBD-Unveränderbarkeit (GoBD)
• ZUGFeRD 1.0 statt 2.0.1+ — ab 2025 nur Versionen ab 2.0.1 als gültige E-Rechnung anerkannt (BMF)
• Falscher BT-3 Code bei Rabatt-Nachträgen — teilweiser Nachlass ist meist 384 (Korrektur), nicht 381 (Storno)
• Wortwahl Gutschrift im Dokument ohne Abgrenzung zu § 14 Abs 2 UStG — Risiko § 14c-Diskussion (BMF)
• Rundungsdifferenzen bei Teil-Korrekturen — im Profil ZUGFeRD 2.3 EXTENDED explizit adressiert (FeRD)

Buchhaltungs-Integration: DATEV und andere

Eine sauber kodierte Stornorechnung oder Korrektur ist nur dann operativ nützlich, wenn sie in der Buchhaltung automatisch als Minderung des ursprünglichen Belegs gebucht wird. Unsere DATEV-Schnittstelle verwertet die BT-3-Codes und die BG-3-Referenz direkt; weitere Details beschreiben wir im Beitrag DATEV-Schnittstelle für E-Commerce-Buchhaltung. Für größere ERP-Umgebungen — etwa in Verbindung mit Dynamics 365 Business Central oder einer SAP-Integration — bilden wir die Storno-Prozesse über Middleware ab, damit jeder Buchungssatz im ERP eindeutig auf die Originalrechnung verweist.

In der Praxis ist die Reihenfolge entscheidend: Das ZUGFeRD-Dokument wird zuerst im Shop erzeugt, dort validiert und signiert, anschließend an den Kunden versendet — und erst dann an die Buchhaltung übergeben. Wer die Reihenfolge umdreht (erst in der Buchhaltung buchen, dann das Dokument erzeugen), riskiert Abweichungen zwischen versendetem Beleg und buchhalterischer Fassung. Diese Abweichungen sind typische Stolperfallen in GoBD-Prüfungen, weil der Prüfer in der Regel verlangt, dass der Beleg, den der Kunde erhalten hat, deckungsgleich mit dem Buchungsbeleg ist. Gute Integrationen lösen das über eine Event-Bus-Architektur, in der das ZUGFeRD-XML die einzige Quelle der Wahrheit für Rechnung, Storno und Korrektur ist.

Validierung und Prüftools

Für die technische Prüfung einer ZUGFeRD-Stornorechnung oder Korrektur kommen in der Regel drei Prüfebenen zum Einsatz: Schema-Validierung gegen UN/CEFACT CII, Schematron-Regeln nach EN 16931 und die vom KoSIT veröffentlichte Validator-Konfiguration (KoSIT). Welches konkrete Werkzeug im Projekt eingesetzt wird, hängt von Infrastruktur und ERP ab — wir bleiben bei der Auswahl bewusst neutral und richten uns nach den Anforderungen der Finanzbuchhaltung und des Empfängers. Wichtiger als die Tool-Frage ist, dass jede ausgehende E-Rechnung vor dem Versand in einer Prüfpipeline landet und dass Validierungsergebnisse revisionssicher archiviert werden — analog zum GoBD-Anforderungsprofil. Für Shop-Betreiber empfehlen wir eine Integration in die Shopware-Deployment-Pipeline, sodass Validierung auf Code-Ebene ebenso stattfindet wie im Live-Betrieb.

Gerade bei Stornos und Korrekturen sind die KoSIT-Schematron-Regeln streng: Fehlende BG-3-Referenzen, unplausible Summenfelder oder inkonsistente Steuerkategorien werden zuverlässig als Fatal- oder Error-Meldung gemeldet (KoSIT). In unseren Projekten richten wir die Prüfpipeline so ein, dass diese Schwere-Klassen den Versand blockieren, während Warnings protokolliert, aber nicht blockiert werden. Das verhindert, dass Shop-Dokumente beim Empfänger-System abgelehnt werden und dort für manuelle Nacharbeit sorgen — ein Szenario, das im B2B-Kontext schnell zu Zahlungsverzug und zu Streit über Skonti führt.

Umsetzungs-Roadmap bis 2028

1. Bis Q2 2026: Ist-Analyse — Welche Dokumenttypen erzeugt der Shop aktuell (PDF, ZUGFeRD 1.x, XRechnung)? Inventur aller Stornovorgänge der letzten 12 Monate
2. Q3 2026: ZUGFeRD 2.3 Upgrade — Migration auf EN-16931-konformes Format, Shopware-Templates für 380/381/384 anpassen
3. Q4 2026: Workflow-Harmonisierung — Retouren- und Widerrufs-Events an die Dokumentengenerierung koppeln (siehe PIM-Strategie)
4. Q1 2027: Versand-Pipeline — automatisierter Versand an Kunden und DATEV / ERP, Validierung vor jedem Versand
5. Bis 01.01.2027: 800.000-EUR-Schwelle — wer darüber liegt, muss E-Rechnungen versenden können (BMF)
6. Bis 01.01.2028: ausnahmslose Versandpflicht — alle B2B-Transaktionen im Shop komplett auf E-Rechnung umgestellt (BMF)

Storno-Sauberkeit als Compliance-Fundament

Mit den Pflichtfristen 2025/2027/2028 wird die Behandlung von Storno, Gutschrift und Korrektur zu einem Kern-Element jedes E-Commerce-Workflows. Wer die drei Codes 380/381/384 sauber trennt, BG-3 Referenzen korrekt setzt und die GoBD-Unveränderbarkeit respektiert, reduziert das Risiko von Rückfragen der Finanzverwaltung und schafft die Grundlage für eine belastbare Buchhaltungsautomatisierung. Die XICTRON-ZUGFeRD-Beratung begleitet Shops bei Analyse, Template-Anpassung und Integration — von Shopware 6 bis hin zur ERP-Anbindung.

Wer den Storno-Workflow früh sauber aufsetzt, profitiert doppelt: Die technische Basis trägt die kommenden Fristen 2027 und 2028 mit, und die Buchhaltung gewinnt Zeit, weil Retouren, Widerrufe und Teilerstattungen nicht mehr manuell nachbearbeitet werden müssen. Gerade in Shopware-Projekten mit DATEV- oder ERP-Kopplung ist der saubere Umgang mit den BT-3-Codes 381 und 384 der Hebel, der aus einer reinen Compliance-Übung ein echtes Effizienz-Upgrade macht — und gleichzeitig die Prüfsicherheit nach GoBD erhöht (GoBD).