Startseite › Wissen › BR-DE-17

BR-DE-17: Rechnungstyp-Code (BT-3) nicht vorgesehen

BR-DE-17 ist eine Warnung. XRechnung sieht für den Rechnungstyp (BT-3) nur diese Codes aus UNTDID 1001 vor: 326 (Teilrechnung), 380 (Rechnung), 384 (Korrekturrechnung), 389 (Gutschrift im Gutschriftverfahren / Self-billing), 381 (Gutschrift/Rechnungskorrektur als Credit Note), 875, 876 und 877 (Bau-Abschlags-, Teilschluss- und Schlussrechnung). Andere Codes sind nach EN 16931 erlaubt, sollen in XRechnung aber nicht verwendet werden.

Originaltext der Regel

Warnung BR-DE-17 · Herkunft: XRechnung (deutsche Regel der KoSIT)

Mit dem Element "Invoice type code" (BT-3) sollen ausschließlich folgende Codes aus der Codeliste UNTDID 1001 übermittelt werden: 326 (Partial invoice), 380 (Commercial invoice), 384 (Corrected invoice), 389 (Self-billed invoice) und 381 (Credit note),875 (Partial construction invoice), 876 (Partial final construction invoice), 877 (Final construction invoice).

Technische Prüfung (Schematron/XPath)

Regelwerk	Kontext	Test
XRechnung, UBL	`/ubl:Invoice \| /cn:CreditNote`	`normalize-space(cbc:InvoiceTypeCode) = $supportedInvAndCNTypeCodes or normalize-space(cbc:CreditNoteTypeCode) = $supportedInvAndCNTypeCodes`
XRechnung, CII	`/rsm:CrossIndustryInvoice`	`normalize-space(rsm:ExchangedDocument/ram:TypeCode) = ('326', '380', '384', '389', '381', '875', '876', '877')`

Aus der offiziellen XRechnung 3.0.2 (KoSIT-Konfiguration 2026-08-31).

Typische Ursachen

Für Anzahlungs- oder Vorauszahlungsrechnungen wurde 386 verwendet.
Die Software nutzt einen allgemeinen Code wie 393 oder 751.

So beheben Sie den Fehler

Einen der vorgesehenen Codes verwenden – für normale Rechnungen 380.
Bei Unsicherheit mit dem Empfänger klären, welcher Code erwartet wird.

Beispiel: vorher und nachher

Fehlerhaft

<cbc:IssueDate>2026-10-01</cbc:IssueDate>
<cbc:DueDate>2026-10-15</cbc:DueDate>
<cbc:InvoiceTypeCode>386</cbc:InvoiceTypeCode>
<cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
<cbc:BuyerReference>04011000-1234512345-06</cbc:BuyerReference>

Korrigiert

<cbc:IssueDate>2026-10-01</cbc:IssueDate>
<cbc:DueDate>2026-10-15</cbc:DueDate>
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
<cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
<cbc:BuyerReference>04011000-1234512345-06</cbc:BuyerReference>

Ausschnitt aus einer vollständigen XRechnung 3.0 (UBL). Ergebnis mit dem KoSIT-Validator: Die fehlerhafte Variante erzeugt BR-DE-17; die korrigierte Variante wird akzeptiert.

Häufige Fragen

Wird die Rechnung wegen BR-DE-17 abgelehnt?

Der KoSIT-Validator stuft BR-DE-17 als Warnung ein; die Rechnung bleibt technisch gültig. Ob ein Empfänger sie annimmt, entscheidet er selbst.

Hintergrund: XRechnung vs. ZUGFeRD: Welches Format passt?