Leitfaden

Storno, Rechnungskorrektur, Gutschrift: 384 oder 381?

Drei Vorgänge, die im Alltag alle „Gutschrift“ heißen — und drei Typcodes, von denen einer (381) in der UBL-Invoice-Syntax abgelehnt wird. Welcher Code zu welchem Vorgang gehört, wie das JSON aussieht und was der Validator dazu sagt.

Aktualisiert am 22. September 2026

Welche drei Dinge heißen auf Deutsch Gutschrift?

Das Wort „Gutschrift“ steht im deutschen Rechnungsalltag für drei verschiedene Vorgänge, und EN 16931 gibt jedem einen eigenen Typcode (BT-3, Codeliste UNTDID 1001). Wer den Code nach dem Wort auf dem Beleg wählt statt nach dem Vorgang, landet schnell beim falschen — und in einer UBL-Invoice bei einer Ablehnung.

Die dritte Zeile ist die Falle: Im Umsatzsteuerrecht ist die „Gutschrift“ keine Rückerstattung, sondern eine Rechnung, die der Kunde für den Lieferanten ausstellt. Ein Storno ist umsatzsteuerlich eine Rechnungsberichtigung — und in EN 16931 deshalb eine 384, keine 381 und erst recht keine 389. Der Typcode transportiert die Bedeutung eindeutig; das Wort auf dem PDF tut das nicht.

Wie storniere ich eine Rechnung?

Die KoSIT hat die Frage im Issue #58 des XRechnung-Validator-Repositories beantwortet. Die Position der KoSIT-Mitarbeiter dort: Typ 381 „Credit Note“ ist für kaufmännische Gutschriften gedacht, nicht für Rechnungskorrekturen. Ein Storno ist eine hundertprozentige Rechnungskorrektur und wird als 384 „Corrected Invoice“ ausgestellt, bei der die Vorzeichen der Mengen (BT-129) und der Beträge umgekehrt sind. Dass negative Mengen und ein negativer Zahlbetrag in einer UBL-Invoice zulässig sind, zeigt die offizielle XRechnung-3.0.2-Testsuite: Sie enthält Instanzen mit negativer InvoicedQuantity und eine mit negativem PayableAmount, die der Validator akzeptieren muss — ein komplett negatives Storno als 384 ist allerdings nicht darunter; ihre einzige 384 ist eine Ersatzrechnung mit positiven Mengen.

Im normbill-Request sieht ein vollständiges Storno so aus:

{
  "format": "xrechnung-3.0",
  "invoice": {
    "number": "RE-2026-0142-S",
    "issue_date": "2026-09-22",
    "type_code": "384",
    "preceding_invoice": "RE-2026-0142",
    "buyer_reference": "04011000-1234512345-06",
    "seller": {
      "name": "Muster Lieferant GmbH", "vat_id": "DE123456789",
      "address": { "country": "DE", "city": "Berlin", "postal_code": "10115" },
      "contact": { "name": "Billing", "phone": "+49 30 1234567",
                   "email": "billing@lieferant.example" }
    },
    "buyer": {
      "name": "Beispiel Kunde AG",
      "address": { "country": "DE", "city": "Hamburg", "postal_code": "20095" },
      "contact": { "email": "ap@kunde.example" }
    },
    "payment": { "iban": "DE89370400440532013000" },
    "lines": [
      { "name": "Beratungsleistung", "qty": -10, "unit_price": 100, "vat": 19 }
    ]
  }
}

Drei Dinge daran sind bewusst so:

• Das Vorzeichen steht in der Menge, nicht im Preis. unit_price muss größer oder gleich null sein (BR-27); ein negativer Preis kommt gar nicht bis zum Validator, sondern wird schon vom Request-Schema mit 400 und dem Hinweis auf BR-27 abgewiesen. Mit qty: -10 rechnet normbill die Summen selbst: netto −1.000,00, USt −190,00, brutto −1.190,00.
• preceding_invoice nennt die stornierte Rechnung. Fehlt das Feld bei einer 384, meldet die Stufe-1-Prüfung BR-DE-26 als Warnung unter path: "invoice.preceding_invoice" — das Dokument bleibt gültig, aber der Empfänger kann das Storno keiner Rechnung zuordnen. Setzen Sie es immer.
• Die Nummer ist neu. Ein Storno ist ein eigenes Dokument mit eigener Rechnungsnummer (BT-1); die alte Nummer steht nur in BT-25.

Ob eine Teilkorrektur als Differenz (nur die zurückgenommenen Positionen mit negativer Menge) oder als vollständige Ersatzrechnung ausgestellt wird, schreibt die XRechnung nicht vor — das ist eine Vereinbarung mit dem Empfänger; beides ist eine 384 mit preceding_invoice. Das Vorzeichen gehört in beiden Fällen in die Menge, nie in den Preis. Eine Ersatzrechnung trägt positive Mengen und einen positiven Zahlbetrag — und braucht dann wie jede Rechnung ein due_date oder payment.terms (BR-CO-25).

Wann ist 381 richtig — und warum nicht in einer UBL-Invoice?

Eine 381 ist die kaufmännische Gutschrift: ein Bonus, eine Kulanzerstattung, ein nachträglicher Rabatt — ein Guthaben, das keine bestimmte Rechnung korrigiert. Die Codeliste UNTDID 1001 führt 381 in der UBL-Bindung von EN 16931 aber nur für den Dokumenttyp CreditNote, nicht für Invoice. In CII gibt es diese Trennung nicht: Der einzige Wurzelknoten CrossIndustryInvoice trägt den Typcode im TypeCode-Element, und 381 ist dort gültig.

Deshalb gibt normbill 381 in den CII-Syntaxen aus (xrechnung-cii-3.0, zugferd-2.x, facturx-1.0). In den UBL-Formaten (xrechnung-3.0, peppol-bis-3.0) meldet die Stufe-1-Vorprüfung eine 381 als BR-CL-01 unter path: "invoice.type_code" — die Antwort ist ein 422, es wird kein XML zurückgegeben; im JSON-Playground auf der Startseite erscheint dieselbe Meldung. Zwei Auswege:

• Format auf xrechnung-cii-3.0 umstellen. Das ist die zweite offizielle XRechnung-Syntax; normbill prüft sie wie die UBL-Variante gegen den KoSIT-Validator.
• Als 384 ausdrücken, wenn das Guthaben in Wahrheit eine Rechnung korrigiert — dann ist 384 mit preceding_invoice ohnehin der richtige Code.

Ein UBL-CreditNote-Dokument (eigener Wurzelknoten, eigenes KoSIT-Szenario „EN16931 XRechnung (UBL CreditNote)“ in der gepinnten Konfiguration) gibt normbill heute nicht aus; auch /v1/invoices/parse akzeptiert in UBL nur Invoice-Dokumente.

Vorzeichen bei 381: Die XRechnung macht heute keine Vorgabe, ob eine kaufmännische Gutschrift positive oder negative Beträge trägt. In demselben Thread hat ein CEN-Editor am 2. Januar 2025 angekündigt, dass die anstehende Revision der EN 16931-1 negative Gutschriftssummen nicht mehr zulassen wird. Positive Mengen auf einer 381 sind damit die zukunftssichere Form — das Dokument selbst sagt durch den Code, dass es ein Guthaben ist. Beachten Sie dabei BR-CO-25: Ein positiver Zahlbetrag verlangt ein due_date oder payment.terms (z. B. „Verrechnung mit der nächsten Rechnung“).

Welche Regeln prüfen Typcode und Vorzeichen?

Wie geht es weiter?

Validator · Playground · Docs · KoSIT-Fehlermeldungen lesen

English version →