# Gutschriften und Korrekturen
> https://billhorse.com/leitfaeden/gutschriften-und-korrekturen/
Ob ein Empfängersystem ein Dokument als Rechnung bucht oder als Gutschrift gegenbucht, entscheidet ein einziges Feld: der [Rechnungstyp-Code (BT-3)](/begriffe/bt-3/). Er trägt einen Code aus der UNTDID-Codeliste 1001, dem UN/EDIFACT-Verzeichnis der Dokumentfunktionen, aus dem die EN 16931 eine Teilmenge zulässt. Ein falscher Code erzeugt keinen Schema-Fehler — er erzeugt falsch gebuchte Belege. Dieser Leitfaden ordnet 381, 384 und die 380er-Familie ein und zeigt, wie Vorrechnungs-Referenz und Vorzeichenlogik in XRechnung und ZUGFeRD korrekt aussehen.
## 381, 384 oder 380er-Familie?
Eine **Gutschrift (381)** ist ein eigenständiges kaufmännisches Dokument, das dem Käufer einen Betrag gutschreibt — etwa nach Retoure, Reklamation oder nachträglichem Rabatt. Sie trägt eine eigene Nummer und macht die Vorrechnung nicht ungültig, sondern gleicht sie ganz oder teilweise aus. Nicht zu verwechseln mit der umsatzsteuerlichen „Gutschrift" nach § 14 Abs. 2 UStG (Abrechnung durch den Leistungsempfänger, Self-Billing): das ist Code 389.
Eine **korrigierte Rechnung (384)** ersetzt eine frühere Rechnung inhaltlich — falscher Steuersatz, falsche Adresse, falsche Leitweg-ID. Fachlich tritt die 384 vollständig an die Stelle der Vorrechnung, die damit hinfällig ist.
Für Abschlags-Szenarien gibt es die **380er-Familie**: 326 (Teilrechnung), 386 (Anzahlungsrechnung) und die Schlussrechnung als gewöhnliche 380, die geleistete Anzahlungen über BT-113 verrechnet.
Eine Syntax-Eigenheit von UBL: die 381 wird dort üblicherweise als eigenes Wurzelelement `CreditNote` mit `cbc:CreditNoteTypeCode` transportiert, während 380/384/326 in der `Invoice`-Wurzel mit `cbc:InvoiceTypeCode` stehen. CII — die Syntax von ZUGFeRD und Factur-X — kennt nur `CrossIndustryInvoice`; der Code steht dort immer in `ram:ExchangedDocument/ram:TypeCode`:
```xml
384
381
381
```
## Die Vorrechnung referenzieren: BG-3
Eine Gutschrift oder Korrektur ohne Bezug ist für die Kreditorenbuchhaltung des Empfängers kaum verwertbar. Die EN 16931 sieht dafür die Gruppe [BG-3](/begriffe/bg-3/) vor: die Nummer der Vorrechnung ([BT-25](/begriffe/bt-25/)) und optional deren Ausstellungsdatum ([BT-26](/begriffe/bt-26/)). Die Gruppe ist laut Norm optional und wiederholbar (Sammelgutschrift über mehrere Rechnungen), praktisch sollte aber jede 381 und 384 sie führen — viele Workflow-Systeme matchen darüber automatisch.
In UBL:
```xml
RE-2026-0417
2026-05-12
```
In CII sitzt die Referenz im `ApplicableHeaderTradeSettlement`; das Datum verlangt wie üblich `format="102"` (JJJJMMTT):
```xml
RE-2026-0417
20260512
```
## Vorzeichenlogik: positive 381 oder negative 384?
Die EN 16931 lässt in den Summenfeldern (BT-106 bis BT-115) negative Werte ausdrücklich zu und schreibt kein bestimmtes Muster vor. In der Praxis haben sich zwei Konventionen etabliert.
Erstens die 381 mit **positiven Beträgen**: der Dokumenttyp selbst kehrt die Buchungsrichtung um, die Beträge beziffern nur die Höhe der Gutschrift. Zweitens die **negative Rechnung**: eine 380 oder 384 mit negativen Summen, in XRechnung seit Version 2.0 zulässig und dort verbreitet.
Was man vermeiden sollte, ist die Kombination: eine 381 mit negativen Summen wird von vielen Empfängersystemen doppelt negiert oder schlicht abgewiesen. Wählen Sie ein Muster — im Zweifel das, das der Empfänger nennt — und ziehen Sie es durch.
Durchziehen heißt: die BR-CO-Arithmetikregeln der EN 16931 rechnen vorzeichenbehaftet und gelten unverändert. BT-106 muss die Summe der Positionsbeträge sein, BT-112 muss BT-109 + BT-110 ergeben. Wer nur die Endsumme negiert, die Positionen aber positiv lässt, scheitert zuverlässig an der Prüfung.
## Typische Validierungsfehler
Bei Gutschriften und Korrekturen sehen wir vor allem fünf Meldungen. [BH-TYPE-01](/regeln/bh-type-01/) warnt vor exotischen Typ-Codes aus dem vollen UNTDID-Katalog (etwa 80 oder 261) — bleiben Sie bei 380, 381, 384 und 326. [BR-CO-10](/regeln/br-co-10/) schlägt an, wenn BT-106 nicht der Summe der Positionsbeträge (BT-131) entspricht — der Klassiker: Summen negiert, Positionen nicht. [BR-CO-13](/regeln/br-co-13/) trifft Korrekturen, die Nachlässe oder Zuschläge (BT-107/108) aus der Vorrechnung übernehmen, ohne das Vorzeichen mitzudrehen. [BR-CO-14](/regeln/br-co-14/) meldet eine USt-Summe, die nicht zur Aufschlüsselung (BG-23) passt — typisch, wenn beim Vorzeichenwechsel die Kategoriebeträge vergessen wurden. Und [BR-CO-15](/regeln/br-co-15/) erwischt Bruttosummen, die mit Absolutbeträgen statt vorzeichenrichtig aus BT-109 + BT-110 gebildet wurden.
## Vor dem Versand prüfen
Der [Billhorse-Validator](/) prüft Typ-Code, Vorrechnungs-Referenz und die komplette BR-CO-Arithmetik direkt im Browser — die Datei bleibt auf Ihrem Rechner. Dieselbe Engine gibt es als [API](/api/) mit den Endpunkten validate und parse, derzeit in Private Beta.