BR-CL-01EN 16931
Dokumentart nicht zulässig
Die Dokumentart (BT-3) trägt einen Code, den eine Rechnung nicht haben darf. In einer UBL-Rechnung sind 380 (Rechnung), 384 (Korrektur) und 389 (Selbstfakturierung) zulässig. Die 381 gehört nicht dazu: Eine Gutschrift ist in UBL ein eigenes Dokument, keine Rechnung mit anderem Code.
Wortlaut der Meldung
[BR-CL-01] The document type code MUST be coded by the invoice and credit note related code lists of UNTDID 1001.
Betroffene Felder: BT-3 Invoice type code
Stand: Juli 2026 · Geprüft und geschrieben von Pascal Wagner
Warum das passiert
- Für eine Gutschrift wurde die Dokumentart auf 381 gestellt, das Dokument aber weiter als Rechnung geschrieben. In UBL ist eine Gutschrift ein eigenes Wurzeldokument („CreditNote“) mit eigenem Nummernkreis — der Code allein macht daraus keine.
- Ein Code aus einer anderen Liste ist im Feld gelandet: 875, 876 und 877 (Teilrechnungen im Bauwesen) sind in der Norm gültige Codes, aber nicht in der Liste, die für eine Rechnung gilt.
- Das Feld wurde mit einer internen Belegart des Vorsystems gefüllt („RE“, „GS“, „AR“) statt mit einem Code nach UNTDID 1001.
- Ein Zahlendreher: 830 statt 380 ist der Klassiker.
So behebst du es
- Für eine normale Rechnung die 380 setzen, für eine Abschlagsrechnung die 326, für Korrektur und Storno die 384.
- Für einen Storno nimm die 384 mit Bezug auf die ursprüngliche Rechnung (BG-3) und dreh die Mengen ins Minus — das ist der Weg, den der Rechnungslotse über „Stornieren“ geht, und der Empfänger kann ihn seinem Original zuordnen.
- Willst du wirklich eine Gutschrift als eigenen Beleg ausstellen, braucht es ein Programm, das UBL-CreditNote schreibt. Dieses hier tut es nicht, und ein Code allein reicht dafür nicht.
Was die Regel nicht prüft
DIESELBE DATEI KANN GRÜN UND ROT SEIN. Am 3. August 2026 gegen den Prüfdienst gemessen: Eine Rechnung mit der Dokumentart 381 fällt als XRechnung (UBL) mit dieser Regel durch — als ZUGFeRD (CII) besteht sie ohne jede Beanstandung. Der Grund ist keine Nachlässigkeit der Prüfung, sondern die Syntax: CII kennt kein eigenes Gutschrift-Dokument, dort ist die 381 an einer Rechnung formal in Ordnung. Wer also nur sein ZUGFeRD-PDF prüft und dieselben Daten später als XRechnung an eine Behörde schickt, bekommt die Ablehnung erst dort. Deshalb prüft der Rechnungslotse bei jeder Erzeugung die UBL-Fassung mit, auch wenn nur ein PDF gewünscht ist.
Was der Empfänger sieht
Nichts, die Datei wird abgewiesen — sein Rechnungsportal liest die Dokumentart, bevor es den Beleg annimmt. Kommt sie über einen Weg ohne Prüfung durch, ist der Schaden größer als eine Ablehnung: Eine als Gutschrift gekennzeichnete Rechnung kann in der Buchhaltung des Empfängers mit falschem Vorzeichen landen.
Wenn die Rechnung schon raus ist
Dokumentart berichtigen und erneut senden. Die Nummer bleibt dieselbe, solange der Empfänger den Beleg abgewiesen hat — es ist keine Korrektur, sondern derselbe Beleg in gültiger Form. Hat er ihn dagegen angenommen und verbucht, gehört die Berichtigung als 384 mit Bezug hinterher, und die alte Nummer bleibt stehen (§ 14 Abs. 4 Nr. 4 UStG).
Tritt oft zusammen auf mit
Quelle der Regel: EN 16931. Diese Seite beschreibt, wie sich die Regel in der Praxis auswirkt — sie ersetzt nicht den Normtext und ist keine Rechts- oder Steuerberatung. Fehlt etwas oder stimmt etwas nicht? Schreib uns.