Storno, Gutschrift, Korrektur: wie Sie eine Rechnung in XRechnung und ZUGFeRD richtig aufheben
BT-3 ist drei Zeichen lang und entscheidet, ob Ihr Kunde eine Forderung oder deren Aufhebung in den Büchern hat — kein Validator kann das für Sie prüfen.
Was wir bei Kunden immer wieder sehen: Die E-Rechnung ist eingeführt, die Rechnungen laufen durch — und dann kommt der erste Storno. Oder eine Mängelrüge. Oder eine Rückgabe. Und plötzlich läuft es nicht mehr. Nicht weil die Technik versagt, sondern weil der Storno-Prozess nie sauber aufgesetzt wurde. Er war im PDF-Zeitalter nie nötig — ein Mensch hat das Minuszeichen gelesen und die Absicht verstanden. In der strukturierten E-Rechnung liest kein Mensch mehr mit. Bevor die E-Rechnung reibungslos funktioniert, müssen oft erst die Prozesse aufgeräumt werden — und der Storno-Fall zeigt das am deutlichsten.
Der unsichtbare Fehler
Wer 380 stehen lässt, wo 381 hingehört, verschickt ein technisch einwandfreies, sauber validierendes, durch PEPPOL zugestelltes Dokument — das die Buchhaltung des Empfängers als zweite Forderung verbucht statt als deren Aufhebung.
Die Begriffe: vier Wörter, drei Sachverhalte, ein Dauermissverständnis
Das größte Hindernis bei diesem Thema ist die Sprache. „Gutschrift" bedeutet im deutschen Geschäftsalltag drei verschiedene Dinge, und nur eines davon ist gemeint, wenn der Standard von einer credit note spricht.
| Begriff | Was gemeint ist | BT-3 |
|---|---|---|
| Stornorechnung | Aufhebung einer Rechnung in voller Höhe. Kein Rechtsbegriff des UStG, sondern kaufmännische Praxis. | 381 |
| Gutschrift (kaufmännisch, Korrektur) | Minderung des Entgelts – ganz oder teilweise: Rabatt, Retoure, Mängelrüge, Preisnachlass. Das ist die credit note der EN 16931. | 381 |
| Gutschrift (echte, Selbstfakturierung) | Der Leistungsempfänger rechnet ab (§ 14 Abs. 2 Satz 5 UStG). Keine Korrektur, sondern eine ganz normale Rechnung – nur vom anderen aus geschrieben. | 389 |
| Korrigierte / berichtigte Rechnung | Die ursprüngliche Rechnung wird ersetzt, nicht aufgehoben. Ein Dokument, das an die Stelle des alten tritt. | 384 |
Storno und Gutschrift sind technisch dasselbe.
Der Standard kennt keinen eigenen Storno-Typ. Eine Stornorechnung ist eine Gutschrift über den vollen Rechnungsbetrag, eine Teilgutschrift eine über einen Teil davon. Beide sind 381. Wer in seinem ERP zwei getrennte Belegarten hat, mappt sie auf denselben Code — der Unterschied liegt im Betrag, nicht im Typ.
Die „echte" Gutschrift ist keine Gutschrift.
Das ist der teuerste Begriffsfehler überhaupt. Beim Gutschriftverfahren nach § 14 Abs. 2 Satz 5 UStG stellt der Kunde die Abrechnung aus — typisch bei Handelsvertretern, Lizenzabrechnungen, Schrott- und Agrarhandel. Das ist eine Rechnung, sie erhöht den Umsatz des Leistenden und trägt den Code 389, nicht 381. Wer eine Selbstfakturierung als 381 verschickt, meldet dem Empfängersystem eine Entgeltminderung, wo eine Forderung hingehört.
Storno ≠ Korrektur.
381 hebt auf, 384 ersetzt. Weg A (Storno + Neu): Rechnung R-1000 → Gutschrift G-0007 über den vollen Betrag → neue Rechnung R-1001. Drei Belege, jeder für sich vollständig. Weg B (Berichtigung): Rechnung R-1000 → korrigierte Rechnung R-1001 mit BT-3 = 384 und Bezug auf R-1000. Weg A ist die robustere Variante, weil er auf Empfängerseite keine Interpretation verlangt.
Praktischer Hinweis: Nennen Sie ein Korrekturdokument nicht „Gutschrift". Die Finanzverwaltung sieht in einem Papier mit der Überschrift „Gutschrift", das der Leistende ausstellt, ein § 14c-Risiko, weil es wie eine Abrechnung des Empfängers aussieht. „Rechnungskorrektur", „Stornorechnung" oder „Korrekturbeleg" sind die unverfänglichen Bezeichnungen. In der E-Rechnung entscheidet zwar BT-3 und nicht die Überschrift — aber das Sichtformat des ZUGFeRD-PDF liest am Ende doch ein Mensch.
Der Codevorrat: welche Werte BT-3 annehmen darf
Die EN 16931 erlaubt einen großen Teil der UNTDID-1001-Codeliste. Die XRechnung schränkt über BR-DE-17 auf eine Teilmenge ein:
| Code | Bedeutung | Wann |
|---|---|---|
326 | Teilrechnung | Abrechnung einer abgeschlossenen Teilleistung |
380 | Handelsrechnung | Standardfall |
381 | Gutschrift (credit note) | Storno, Teilstorno, Entgeltminderung |
384 | Korrigierte Rechnung | Ersetzt eine fehlerhafte Rechnung vollständig |
389 | Selbstfakturierte Rechnung | Gutschriftverfahren des Leistungsempfängers |
875 / 876 / 877 | Abschlags-, Teilschluss-, Schlussrechnung Bau | Bauleistungen |
Der Sonderfall UBL: Invoice oder CreditNote?
CII (ZUGFeRD, Factur-X, XRechnung-CII) kennt genau einen Dokumenttyp. Ob Rechnung oder Gutschrift, entscheidet allein ram:TypeCode.
UBL kennt zwei getrennte Wurzelelemente: <ubl:Invoice> und <ubl:CreditNote> — mit eigenem Schema, eigenem Namensraum und eigenen Elementnamen (cac:CreditNoteLine statt cac:InvoiceLine). Die Peppol-Regeln PEPPOL-EN16931-P0100 und P0101 setzen das durch: In einem Invoice-Dokument ist 381 verboten.
Umsetzungsregel: In UBL entscheidet der Typ-Code über das Dokumentschema, nicht nur über ein Feld. Ihr Generator muss beim Storno einen anderen Serialisierungspfad nehmen. Das ist der häufigste Grund, warum in Projekten „die Rechnung läuft, die Gutschrift nicht".
Die BT-Felder: was konkret gesetzt wird
Storno / Gutschrift (BT-3 = 381)
| BT | Feld | Vorgabe | Pflicht |
|---|---|---|---|
BT-3 | Rechnungsart | 381 | ja |
BT-1 | Belegnummer | Eigene, neue, fortlaufende Nummer. Nie die der stornierten Rechnung. | ja |
BT-2 | Belegdatum | Datum der Ausstellung des Stornos, nicht der Originalrechnung | ja |
BT-25 | Nummer der vorausgegangenen Rechnung | Nummer der stornierten / korrigierten Rechnung | faktisch ja |
BT-26 | Datum der vorausgegangenen Rechnung | Ausstellungsdatum des Originals | empfohlen |
BT-22 | Bemerkung | Klartext: Grund und Bezug | empfohlen |
BT-109 ff. | Beträge | positiv (siehe unten) | ja |
BT-10 | Käuferreferenz | Dieselbe wie im Original (Leitweg-ID!) | ja in XRechnung |
BG-16 | Zahlungsanweisungen | Auch in der Gutschrift Pflicht (BR-DE-1) | ja in XRechnung |
BT-9 | Fälligkeitsdatum | Weglassen oder Zahlungsbedingungen als Klartext | — |
BT-25 ist bei 381 genauso unverzichtbar wie bei 384.
BR-DE-26 verlangt den Vorgängerbezug ausdrücklich nur für die korrigierte Rechnung. Für die Gutschrift gibt es keine solche Regel — ein 381 ohne BG-3 validiert sauber durch. Und ist im Rechnungseingang des Kunden nicht zuordenbar: Die Kreditorenbuchhaltung sieht eine Entgeltminderung ohne Bezug, kann sie keinem offenen Posten zuordnen und legt sie in die Klärung. Behandeln Sie BT-25 bei 381 als Pflichtfeld Ihres eigenen Prozesses.
BG-16 überrascht regelmäßig.
BR-DE-1 verlangt in der XRechnung Zahlungsanweisungen — ohne Ausnahme für Gutschriften. Auch wenn nichts zu zahlen ist und bei einer Erstattung das Geld in die Gegenrichtung fließt, muss mindestens BT-81 gesetzt sein. Bei Erstattung per Überweisung: Code 58 und Ihre eigene IBAN. Bei Verrechnung mit offenen Posten: Code 97 und Hinweis in BT-22.
Korrigierte Rechnung (BT-3 = 384)
Dieselben Felder, mit drei Unterschieden: BT-25 ist über BR-DE-26 hart erzwungen, die Beträge sind die des korrigierten Gesamtbetrags (nicht der Differenz), und BT-9 (Fälligkeit) gehört wieder gesetzt, weil eine Zahlungspflicht besteht.
Häufigster Fehler bei 384: Es wird die Differenz abgebildet statt der korrigierten Gesamtrechnung. Eine korrigierte Rechnung ersetzt das Original vollständig — sie enthält alle Positionen mit den richtigen Werten, nicht nur die Änderung. Wer die Differenz will, braucht 381.
Darf in einer Gutschrift ein negativer Betrag stehen?
Kurz: Nein.
Eine Gutschrift trägt positive Beträge. Das Vorzeichen steckt im Dokumenttyp, nicht in den Zahlen.
Wo das herkommt: die Normenkette
EN 16931-1 selbst
Die Norm definiert Invoice und Credit note als zwei semantische Dokumentarten desselben Modells. Der Kern des Modells ist eine positive Wertdarstellung; welche Richtung der Zahlungsstrom nimmt, ergibt sich aus BT-3.
BR-27 und BR-28 — die harte Grenze
BR-27: Der Nettopreis des Artikels (BT-146) darf nicht negativ sein. BR-28: Der Bruttopreis des Artikels (BT-148) darf nicht negativ sein.
Beide haben Severity fatal. Wer eine Gutschriftsposition mit einem Preis von −1.000,00 € baut, bekommt eine Ablehnung — deterministisch, in jedem konformen Validator, in XRechnung wie in ZUGFeRD wie in Peppol.
Was die Norm nicht verbietet
Der Positionsbetrag BT-131 darf negativ sein (eine Retourenzeile innerhalb einer laufenden Rechnung), und der fällige Betrag BT-115 darf es ausdrücklich ebenfalls. Verboten sind die Preise. Eine Gutschrift lässt sich also nicht dadurch bauen, dass man eine 380 nimmt und alle Preise mit −1 multipliziert.
Peppol schärft nach
Die Regeln PEPPOL-EN16931-P0100 und P0101 trennen in UBL Rechnung und Gutschrift auf Schemaebene. Eine Rechnung mit negativen Beträgen ist im Peppol-Netz strukturell keine Gutschrift — sie ist eine Rechnung über einen negativen Umsatz.
Das Umsatzsteuerrecht dahinter
Die Systematik bildet § 17 UStG ab. Eine Entgeltminderung ist kein negativer Umsatz, sondern eine Berichtigung der Bemessungsgrundlage eines bestehenden Umsatzes. Deshalb braucht das Korrekturdokument einen Bezug auf das, was es korrigiert (BT-25), und deshalb wird der Korrekturbetrag positiv ausgewiesen.
Warum es trotzdem so viele tun
Weil das ERP es so gelernt hat. In der Finanzbuchhaltung ist der Storno eine Gegenbuchung, und Gegenbuchungen haben umgekehrte Vorzeichen. Solange am Ende ein PDF stand, fiel das nie auf; ein Mensch liest „−1.190,00 €" und versteht es. Der Validator versteht es nicht.
Die eigentliche Pointe: eine negative Gutschrift ist eine Forderung.
Ein Beleg vom Typ Minderung über einen Betrag von −1.190,00 € ist, streng gelesen, eine Minderung um einen negativen Betrag — also eine Erhöhung. Formal-logisch ist eine negative Gutschrift eine Rechnung.
Ein Empfängersystem, das den Beleg korrekt auswertet, bucht einen offenen Posten auf der Sollseite statt einer Entgeltminderung. Der Kunde hat dann nicht 1.190,00 € weniger Verbindlichkeit, sondern 1.190,00 € mehr — ohne dass irgendwo ein Fehler gemeldet würde.
Es war immer falsch, es war nur nie nachweisbar. Solange am Ende ein PDF stand, hat ein Mensch das Vorzeichen gelesen und die Absicht verstanden. In der strukturierten Rechnung liest kein Mensch mehr mit. Die Doppelnegation wird von einer Schönheitsfrage zu einer Aussage über den Saldo — BR-27 und BR-28 sind nicht die Ursache des Problems, sondern die Stelle, an der es endlich sichtbar wird.
Umsetzungsregel
✓ Gutschrift: BT-3 = 381, alle Beträge positiv, Bezug in BT-25
✓ Nachlass in einer Rechnung: BT-3 = 380, Nachlass als BG-20 oder BG-27
✗ Nie: negative Preise in BT-146 / BT-148
✗ Nie: eine 380 mit durchgehend negativen Beträgen als Ersatz für 381
Das XML
UBL — Storno als CreditNote
<ubl:CreditNote xmlns:ubl="urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2"
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
<cbc:ID>G-2026-0007</cbc:ID> <!-- BT-1: eigene Nummer -->
<cbc:IssueDate>2026-09-04</cbc:IssueDate> <!-- BT-2 -->
<cbc:CreditNoteTypeCode>381</cbc:CreditNoteTypeCode><!-- BT-3 -->
<cbc:Note>Stornorechnung zu Rechnung R-2026-1000 vom 15.08.2026.
Grund: Leistung wurde nicht erbracht. § 17 Abs. 1 UStG.</cbc:Note>
<cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
<cbc:BuyerReference>04011000-12345-34</cbc:BuyerReference><!-- BT-10 -->
<cac:BillingReference> <!-- BG-3 -->
<cac:InvoiceDocumentReference>
<cbc:ID>R-2026-1000</cbc:ID> <!-- BT-25 -->
<cbc:IssueDate>2026-08-15</cbc:IssueDate> <!-- BT-26 -->
</cac:InvoiceDocumentReference>
</cac:BillingReference>
<cac:PaymentMeans> <!-- BG-16, BR-DE-1 -->
<cbc:PaymentMeansCode>58</cbc:PaymentMeansCode>
<cac:PayeeFinancialAccount>
<cbc:ID>DE02120300000000202051</cbc:ID>
</cac:PayeeFinancialAccount>
</cac:PaymentMeans>
<cac:CreditNoteLine>
<cbc:ID>1</cbc:ID>
<cbc:CreditedQuantity unitCode="H87">10</cbc:CreditedQuantity>
<cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount>
<cac:Item>
<cbc:Name>Storno: Lizenz Modul A, Abrechnung 08/2026</cbc:Name>
<cac:ClassifiedTaxCategory>
<cbc:ID>S</cbc:ID><cbc:Percent>19.00</cbc:Percent>
<cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
</cac:ClassifiedTaxCategory>
</cac:Item>
<cac:Price>
<cbc:PriceAmount currencyID="EUR">100.00</cbc:PriceAmount><!-- BT-146: positiv, BR-27 -->
</cac:Price>
</cac:CreditNoteLine>
<cac:LegalMonetaryTotal>
<cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount>
<cbc:TaxExclusiveAmount currencyID="EUR">1000.00</cbc:TaxExclusiveAmount>
<cbc:TaxInclusiveAmount currencyID="EUR">1190.00</cbc:TaxInclusiveAmount>
<cbc:PayableAmount currencyID="EUR">1190.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>
</ubl:CreditNote>Alle Beträge positiv. Dass es sich um eine Erstattung handelt, sagt ausschließlich CreditNoteTypeCode und das Wurzelelement.
CII — dasselbe in ZUGFeRD / Factur-X
<rsm:ExchangedDocument>
<ram:ID>G-2026-0007</ram:ID>
<ram:TypeCode>381</ram:TypeCode>
<ram:IssueDateTime>
<udt:DateTimeString format="102">20260904</udt:DateTimeString>
</ram:IssueDateTime>
<ram:IncludedNote>
<ram:Content>Stornorechnung zu Rechnung R-2026-1000 vom 15.08.2026.</ram:Content>
</ram:IncludedNote>
</rsm:ExchangedDocument>
...
<ram:ApplicableHeaderTradeSettlement>
<ram:InvoiceCurrencyCode>EUR</ram:InvoiceCurrencyCode>
<ram:ApplicableTradeTax>
<ram:CalculatedAmount>190.00</ram:CalculatedAmount>
<ram:TypeCode>VAT</ram:TypeCode>
<ram:BasisAmount>1000.00</ram:BasisAmount>
<ram:CategoryCode>S</ram:CategoryCode>
<ram:RateApplicablePercent>19.00</ram:RateApplicablePercent>
</ram:ApplicableTradeTax>
<ram:SpecifiedTradeSettlementHeaderMonetarySummation>
<ram:LineTotalAmount>1000.00</ram:LineTotalAmount>
<ram:TaxBasisTotalAmount>1000.00</ram:TaxBasisTotalAmount>
<ram:TaxTotalAmount currencyID="EUR">190.00</ram:TaxTotalAmount>
<ram:GrandTotalAmount>1190.00</ram:GrandTotalAmount>
<ram:DuePayableAmount>1190.00</ram:DuePayableAmount>
</ram:SpecifiedTradeSettlementHeaderMonetarySummation>
<ram:InvoiceReferencedDocument> <!-- NACH MonetarySummation — Reihenfolge beachten! -->
<ram:IssuerAssignedID>R-2026-1000</ram:IssuerAssignedID>
<ram:FormattedIssueDateTime>
<qdt:DateTimeString format="102">20260815</qdt:DateTimeString>
</ram:FormattedIssueDateTime>
</ram:InvoiceReferencedDocument>
</ram:ApplicableHeaderTradeSettlement>Elementreihenfolge in CII: ram:InvoiceReferencedDocument steht nach ram:SpecifiedTradeSettlementHeaderMonetarySummation. Wer die Referenz weiter oben einsortiert, bekommt einen XSD-Fehler, der auf ein ganz anderes Element zeigt.
Korrigierte Rechnung (384) in UBL
<ubl:Invoice ...>
<cbc:ID>R-2026-1001</cbc:ID>
<cbc:IssueDate>2026-09-04</cbc:IssueDate>
<cbc:InvoiceTypeCode>384</cbc:InvoiceTypeCode>
<cbc:Note>Berichtigte Rechnung. Ersetzt Rechnung R-2026-1000 vom 15.08.2026 vollständig.
Korrigiert wurde die USt-IdNr. des Leistungsempfängers. Der Rechnungsbetrag ist
unverändert und nicht erneut zu zahlen, sofern bereits ausgeglichen.</cbc:Note>
<cac:BillingReference> <!-- BR-DE-26: Pflicht bei 384 -->
<cac:InvoiceDocumentReference>
<cbc:ID>R-2026-1000</cbc:ID>
<cbc:IssueDate>2026-08-15</cbc:IssueDate>
</cac:InvoiceDocumentReference>
</cac:BillingReference>
...
</ubl:Invoice>Teilstorno: wenn nur ein Teil der Rechnung weg muss
Technisch ist das dieselbe 381. Der Unterschied liegt ausschließlich im Inhalt: Die Gutschrift enthält nur die zurückgenommenen Teile, nicht die ganze Rechnung.
Ausgangsrechnung R-2026-1000 vom 15.08.2026
| Pos | Bezeichnung | Menge | Einzelpreis | Netto | USt |
|---|---|---|---|---|---|
| 1 | Lizenz Modul A | 10 | 100,00 € | 1.000,00 € | 19 % |
| 2 | Einrichtung, pauschal | 1 | 500,00 € | 500,00 € | 19 % |
| 3 | Schulungsunterlagen (gedruckt) | 20 | 15,00 € | 300,00 € | 7 % |
| Brutto gesamt | 2.106,00 € | ||||
Mengenrückgabe — ein Teil wurde nie geliefert
Drei der zehn Lizenzen waren nicht Vertragsgegenstand. Die Gutschrift enthält eine Position mit gleicher Bezeichnung, gleichem Einzelpreis, gleichem Steuersatz — nur die Menge ist die zurückgenommene (BT-129 = 3, BT-146 = 100,00 unverändert, BT-131 = 300,00). Die Regel: Beim Teilstorno ändert sich die Menge, nie der Preis.
Nachträglicher Preisnachlass — Menge bleibt, Wert sinkt
Mängelrüge auf die Einrichtungspauschale: 20 % Nachlass = 100,00 € netto. Die Versuchung, eine Position "Nachlass" mit −100,00 € anzulegen, scheitert an BR-27. Weg 1 (empfohlen): Gutschriftsposition mit Menge 1, Bezeichnung "Preisnachlass 20 % auf Pos. 2 der Rechnung R-2026-1000", BT-146 = 100,00, Steuersatz 19 %. Der Steuersatz ist immer der der Originalposition, nie der Durchschnittssatz.
Teilstorno über mehrere Steuersätze
Schulungsunterlagen (7 %) gehen zurück, zusätzlich zwei Lizenzen (19 %). Die Gutschrift braucht zwei Positionen und zwei Steuergruppen (BG-23). Pro Steuersatz genau eine BG-23-Gruppe, sonst greift PEPPOL-EN16931-R053. Die Steueraufschlüsselung der Gutschrift muss die der Originalrechnung spiegeln — sonst kann der Empfänger seine Vorsteuerkorrektur nach § 17 UStG nicht je Satz durchführen.
Falscher Steuersatz — hier hilft der Teilstorno nicht
Position 3 wurde mit 7 % abgerechnet, richtig wären 19 % gewesen. Das lässt sich mit einer Teilgutschrift nicht sauber abbilden — es gibt kein Feld für eine isolierte Steuerkorrektur. Der richtige Weg: Vollstorno oder berichtigte Rechnung 384 mit dem korrekten Satz. Bei zu hoch ausgewiesener Steuer: § 14c Abs. 1 UStG — die Steuer wird geschuldet, bis die Rechnung wirksam berichtigt und dem Empfänger zugegangen ist.
Der strukturelle Haken: es gibt keinen Positionsbezug
Die Referenz auf die Originalrechnung steht in BG-3 auf Dokumentebene. Einen Bezug von Gutschriftsposition auf Rechnungsposition kennt das Kernmodell der EN 16931 nicht. Ein empfangendes System kann die Zuordnung nur erraten.
Das ist keine Schwäche der Erkennung, sondern eine Lücke im Datenmodell. Vollstornos lassen sich verlässlich maschinell auflösen, Teilstornos nicht.
Abhilfe heute: (1) Positionsbezug in BT-153 in festem Muster, z. B. Teilstorno zu Pos. 3 der Rechnung R-2026-1000 – Schulungsunterlagen. (2) Originalbezeichnung, -preis und -steuersatz unverändert. (3) In CII EXTENDED steht auf Positionsebene eine strukturierte Dokumentreferenz zur Verfügung.
Wenn das Geld schon geflossen ist
Eine Gutschrift trägt, wie jede Rechnung, einen fälligen Betrag BT-115. Ob etwas zurückfließen muss, hängt nicht vom Beleg ab, sondern davon, ob vorher etwas hingeflossen ist. Das Feld dafür ist BT-113 (gezahlter Betrag), verbunden über BR-CO-16: BT-115 = BT-112 − BT-113 + BT-114
Ausgangsrechnung R-2026-1000 über 2.106,00 € brutto, Teilstorno über 357,00 € brutto:
| Situation | BT-113 | BT-115 | Was beim Empfänger passiert |
|---|---|---|---|
| Rechnung noch offen, Verrechnung | 0,00 € | 357,00 € | Beide Posten stehen offen und werden gegeneinander verrechnet: Zahlbetrag 1.749,00 €. Der Normalfall. |
| Rechnung bezahlt, Erstattung steht aus | 0,00 € | 357,00 € | Der Empfänger legt eine Forderung gegen Sie an und erwartet 357,00 € zurück. Korrekt. |
| Rechnung bezahlt, bereits erstattet | 357,00 € | 0,00 € | Der Beleg dokumentiert nur noch. Es entsteht keine Forderung. |
| Rechnung bezahlt, Verrechnung mit künftiger Rechnung | 0,00 € | 357,00 €, BT-81 = 97 | Offener Guthabenposten, der gegen die nächste Rechnung läuft. Hinweis in BT-22 nötig. |
Kritisch: Zeile 3 fehlt am häufigsten. Wenn das Geld bereits zurücküberwiesen wurde und die Gutschrift trotzdem BT-115 = 357,00 € enthält, legt ein korrektes Kreditorensystem einen offenen Posten über eine Erstattung an, die der Kunde längst bekommen hat.
Der saubere Prozess
Eine Gutschrift ist ein eigener Beleg mit eigener Nummer.
Der Storno bekommt eine neue, fortlaufende Nummer aus Ihrem Nummernkreis — gern ein eigener Kreis (G-…). Die Nummer der stornierten Rechnung wird nie wiederverwendet. Empfängersysteme führen eine Dublettenprüfung über BT-1.
Der Bezug steht in BG-3, nicht im Text.
BT-25 mit der Originalnummer, BT-26 mit deren Datum. Ein Hinweis nur in BT-22 ist für Menschen lesbar und für die automatische Verrechnung im Rechnungseingang wertlos.
Das Storno geht denselben Weg wie das Original.
Ein nur intern storniertes Dokument ist nicht storniert. Solange die Berichtigung dem Empfänger nicht zugegangen ist, bleibt die ausgewiesene Steuer nach § 14c UStG geschuldet, und der Kunde hat einen Beleg, aus dem er Vorsteuer gezogen hat.
Gleiches Format wie das Original.
Die Berichtigung einer E-Rechnung muss selbst in der für sie vorgeschriebenen Form erfolgen — Rechtsgrundlage ist § 31 Abs. 5 Satz 3 UStDV. Wer eine XRechnung storniert, verschickt eine XRechnung — keine PDF-Gutschrift, keine E-Mail.
Beide Fassungen bleiben aufbewahrt.
Original und Korrektur sind zwei aufbewahrungspflichtige Belege. Ein Storno ist keine Löschung. Bei ZUGFeRD gilt das für das eingebettete XML genauso wie für das PDF.
| Schritt | Beleg | BT-3 | BT-1 | BT-25 |
|---|---|---|---|---|
| 1. Fehlerhafte Rechnung | R-2026-1000 | 380 | R-2026-1000 | — |
| 2. Storno | G-2026-0007 | 381 | neu | R-2026-1000 |
| 3. Ersatzrechnung | R-2026-1001 | 380 | neu | optional |
Die typischen Fehler und was sie anrichten
Negative Beträge in der Gutschrift
Ablehnung über BR-27 / BR-28. Der seltene, unangenehme Fall: Ein Generator negiert konsistent alles — dann validiert das Dokument möglicherweise und ist inhaltlich eine Rechnung über einen negativen Umsatz.
380 statt 381
Validiert sauber, wird beim Empfänger als zweite Forderung verbucht. Fällt oft erst bei der Mahnung auf.
381 in einem UBL-Invoice-Dokument
PEPPOL-EN16931-P0100, Ablehnung. Umgekehrt: eine CreditNote mit 380 → P0101.
384 ohne BT-25
BR-DE-26, Ablehnung. Der klassische Fall, wenn der Rechnungstyp konfigurierbar ist, das Referenzfeld aber nicht befüllt wird.
Gutschrift ohne BG-16
BR-DE-1 in der XRechnung, Ablehnung. Die Logik "keine Zahlung, also keine Zahlungsangaben" trägt hier nicht.
Leitweg-ID fehlt im Storno
BR-DE-15. Bei B2G besonders ärgerlich: Die Rechnung war zustellbar, die Gutschrift ist es nicht.
Rechnungsnummer wiederverwendet
Dublettenprüfung des Empfängers verwirft den Beleg.
Storno nur im ERP
§ 14c UStG. Der teuerste Fehler der Liste. Solange die Berichtigung dem Empfänger nicht zugegangen ist, bleibt die Steuer geschuldet.
Korrektur per PDF-Mail zur XRechnung
Formal keine wirksame Berichtigung nach § 31 Abs. 5 UStDV. Der ursprüngliche Steuerbetrag bleibt geschuldet.
Mit rechnungsapi.de
Storno über die API — der Typ-Code steuert Format und Serialisierung, der Vorgängerbezug wird mitgegeben, die Beträge bleiben positiv:
{
"invoice": {
"invoiceNumber": "G-2026-0007",
"invoiceIssueDate": "2026-09-04",
"invoiceTypeCode": "381",
"buyerReference": "04011000-12345-34",
"note": "Stornorechnung zu R-2026-1000 vom 15.08.2026. § 17 Abs. 1 UStG.",
"precedingInvoiceReferences": [
{ "invoiceNumber": "R-2026-1000", "issueDate": "2026-08-15" }
],
"lines": [
{
"name": "Storno: Lizenz Modul A, Abrechnung 08/2026",
"quantity": 10,
"netPrice": 100.00,
"vatRate": 19.0
}
]
}
}Bei invoiceTypeCode 381 und Zielformat XRechnung-UBL wird ein ubl:CreditNote erzeugt — der Schemawechsel passiert automatisch.
Bei ZUGFeRD / CII bleibt es ein Dokument mit ram:TypeCode = 381.
Negative Preise werden vor der Erzeugung abgelehnt, statt in eine Validierungsmeldung beim Empfänger zu laufen.
Die Referenz landet in cac:BillingReference bzw. ram:InvoiceReferencedDocument, inklusive der korrekten Elementreihenfolge in CII.
Checkliste
Vor dem Storno
Entscheidung getroffen: Storno + Neu (381 → 380) oder Berichtigung (384)
Bei 384 geprüft, ob die fünf größten Empfänger den Code als Ersetzung verarbeiten
Bei Selbstfakturierung: 389, nicht 381 — und umgekehrt
Im Beleg
BT-3 = 381 (bzw. 384), nicht 380
BT-1 neu und fortlaufend, Originalnummer nicht wiederverwendet
BT-25 / BT-26 auf die Originalrechnung — bei 384 Pflicht (BR-DE-26), bei 381 Prozesspflicht
Alle Beträge positiv, keine negativen Werte in BT-146 / BT-148 (BR-27, BR-28)
BG-16 gesetzt, auch ohne Zahlung (BR-DE-1)
BT-10 / Leitweg-ID wie im Original (BR-DE-15)
BT-22 mit Grund, Bezug und — bei 384 — Hinweis zum Zahlungsstatus
UBL: ubl:CreditNote bei 381, ubl:Invoice bei 384 (PEPPOL-P0100 / P0101)
CII: InvoiceReferencedDocument nach MonetarySummation
Beim Teilstorno
Nur die zurückgenommenen Teile im Beleg, nicht die ganze Rechnung
Menge reduziert, Einzelpreis unverändert (nicht umgekehrt)
Steuersatz und -kategorie je Position wie im Original
Je Steuersatz genau eine BG-23-Gruppe (PEPPOL-R053)
Positionsbezug nach festem Muster in BT-153
Reine Steuersatzkorrektur: nicht als Teilgutschrift, sondern über Vollstorno oder 384
Zahlungsstatus
Geprüft, ob die Originalrechnung bereits bezahlt ist
Bereits erstattet? BT-113 der Gutschrift setzen, BT-115 = 0,00 €
Zahlung einbehalten und verrechnet? BT-113 der Ersatzrechnung setzen
BR-CO-16 nachgerechnet: BT-115 = BT-112 − BT-113 + BT-114
Negativen BT-115 vermieden — Überhang als separate Gutschrift
Verrechnung oder Erstattung als Klartext in BT-22
Nach dem Storno
Beleg an den Empfänger übermittelt, nicht nur im ERP als Status gesetzt
Gleiches Format wie das Original (§ 31 Abs. 5 Satz 3 UStDV)
Original und Korrektur beide unverändert archiviert, strukturierter Teil maschinell auswertbar
Bei Entgeltminderung: Berichtigung nach § 17 UStG im Voranmeldungszeitraum der Änderung
Gutschrift testen — bevor sie beim Kunden ankommt
Sie stornieren regelmäßig und wollen wissen, ob Ihre Belege beim Empfänger als Aufhebung ankommen? Schicken Sie uns eine echte Gutschrift als XML oder ZUGFeRD-PDF — wir sagen Ihnen innerhalb eines Tages, was in BT-3, BT-25 und den Beträgen steht.
FAQ
Ist eine Stornorechnung dasselbe wie eine Gutschrift?
In der E-Rechnung ja. Beide tragen BT-3 = 381. Der Unterschied liegt nur im Betrag: Das Storno hebt die Rechnung in voller Höhe auf, die Teilgutschrift mindert das Entgelt teilweise. Einen eigenen Storno-Code kennt die EN 16931 nicht.
Darf eine Gutschrift negative Beträge enthalten?
Nein. BR-27 und BR-28 verbieten negative Artikelpreise; das Vorzeichen trägt der Dokumenttyp BT-3 = 381. Negative Beträge sind nur an zwei Stellen zulässig: im Positionsbetrag BT-131 innerhalb einer laufenden Rechnung und im fälligen Betrag BT-115.
Wann 381 und wann 384?
381 hebt auf — meist gefolgt von einer neuen Rechnung. 384 ersetzt die fehlerhafte Rechnung vollständig durch eine korrigierte Fassung. 384 ist die richtige Wahl, wenn nur eine formale Angabe falsch war und die Leistung unverändert bleibt; 381 ist die robustere Variante, weil sie auf Empfängerseite keine Interpretation verlangt.
Braucht die Gutschrift eine eigene Rechnungsnummer?
Ja. Eine neue, fortlaufende Nummer in BT-1. Die Nummer der stornierten Rechnung wird nicht wiederverwendet — weder für die Gutschrift noch für die Ersatzrechnung.
Wie storniere ich nur einen Teil einer Rechnung?
Mit derselben 381, die aber nur die zurückgenommenen Teile enthält. Bei einer Mengenrückgabe spiegeln Sie die Originalposition mit reduzierter Menge und unverändertem Einzelpreis; bei einem Nachlass legen Sie eine Gutschriftsposition über den Minderungsbetrag an. Der Steuersatz ist immer der der Originalposition.
Die Rechnung war schon bezahlt und das Geld ist zurück — was steht in der Gutschrift?
BT-113 in Höhe des erstatteten Betrags, damit BT-115 auf 0,00 € kommt. Sonst legt das Kreditorensystem des Kunden einen offenen Posten über eine Erstattung an, die er längst erhalten hat.
Kann ich eine XRechnung per PDF-Gutschrift stornieren?
Nein. Die Berichtigung muss in derselben Form erfolgen wie die Rechnung, unter Verwendung des entsprechenden Rechnungstyps (§ 31 Abs. 5 Satz 3 UStDV). Ein Korrekturschreiben in einem anderen Format berichtigt die Rechnung nicht — die ausgewiesene Steuer bleibt nach § 14c UStG geschuldet.
Reicht es, den Storno im ERP zu buchen?
Nein. Solange die Berichtigung dem Empfänger nicht zugegangen ist, bleibt die ursprünglich ausgewiesene Steuer nach § 14c UStG geschuldet, und der Kunde behält einen Beleg, aus dem er Vorsteuer gezogen hat.
Verwandte Beiträge
Rechtlicher Hinweis: Dieser Beitrag gibt den Stand vom 04.09.2026 wieder und ersetzt keine steuerliche Beratung. Quellen: EN 16931-1 (BR-27, BR-28, BR-CO-13, BR-CO-15), Peppol BIS Billing 3.0 (PEPPOL-EN16931-P0100/P0101), XRechnung 3.0.2 (BR-DE-1, BR-DE-15, BR-DE-17, BR-DE-26), § 14 Abs. 2, § 14c Abs. 1, § 17 Abs. 1 UStG, § 31 Abs. 5 UStDV, BMF-Schreiben zur E-Rechnung.