BR-DE-17: Rechnungstyp-Code liegt außerhalb der XRechnung-Teilmenge

StandardXRechnung 3.0.2 (KoSIT, deutsche CIUS der EN 16931)SchweregradWarnung: die Rechnung wird angenommen, sollte aber korrigiert werdenSyntaxUBL, CIIGeschäftsbegriffe

BT-3 Invoice type code

Gilt fürXRechnung in UBL- oder CII-Syntax, einschließlich ZUGFeRD-/Factur-X-PDFs mit dem Profil XRECHNUNG. Rechnungen an deutsche öffentliche Auftraggeber (Bund, Länder, Kommunen) müssen sie bestehen.

Offizieller Regeltext

[BR-DE-17] 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).

Warum dieser Fehler auftritt

XRechnung schränkt die UNTDID-1001-Liste ein: In BT-3 sollen nur 326 (Teilrechnung), 380 (Handelsrechnung), 384 (Rechnungskorrektur), 389 (Gutschrift im Gutschriftverfahren), 381 (Gutschrift), 875, 876 und 877 (Bauleistungsrechnungen) verwendet werden. Die Regel vergleicht cbc:InvoiceTypeCode / cbc:CreditNoteTypeCode (UBL) bzw. rsm:ExchangedDocument/ram:TypeCode (CII) mit dieser Liste und gibt sonst eine Warnung aus. Typische Auslöser sind 386 (Vorauszahlungsrechnung), 383 (Belastungsanzeige) oder 82 (Verbrauchsabrechnung), die in EN 16931 gültig sind, von deutschen Behörden aber nicht erwartet werden.

So beheben Sie den Fehler

Belegarten auf die erlaubten Codes mappen: normale Rechnung 380, Abschlags-/Teilrechnung 326, Korrektur 384, Gutschrift 381 (in UBL als cn:CreditNote), Gutschriftverfahren 389, Bau-Abschlags-/Teilschluss-/Schlussrechnung 875/876/877. Eine Anzahlungsanforderung wird üblicherweise als 380 oder 326 mit entsprechender Positionsbeschreibung gesendet; die Schlussrechnung weist bereits gezahlte Beträge dann in BT-113 (gezahlter Betrag) aus. Es ist eine Warnung, viele Empfänger behandeln sie aber als Fehler.

Beispiel (gültig)

<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>

Was der Validator prüft

Geprüftes Element (Kontext):

UBL

/ubl:Invoice | /cn:CreditNote

Test (XPath):

normalize-space(cbc:InvoiceTypeCode) = $supportedInvAndCNTypeCodes         or normalize-space(cbc:CreditNoteTypeCode) = $supportedInvAndCNTypeCodes

CII

/rsm:CrossIndustryInvoice

Test (XPath):

normalize-space(rsm:ExchangedDocument/ram:TypeCode) = ('326', '380', '384', '389', '381', '875', '876', '877')

Rechnung prüfen

Legen Sie Ihre XML- oder PDF-Datei im Validator ab; jede verletzte Regel ist mit ihrer Seite hier verlinkt. Kostenlos, ohne Konto, die Datei wird nicht gespeichert.

Rechnung prüfen →

Dieselbe Prüfung per API:

curl -F file=@invoice.xml https://einvoicechecker.com/v1/validate

Häufige Fragen

Was bedeutet BR-DE-17?

BR-DE-17 ist eine XRechnung-Regel: 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).

Wird meine Rechnung wegen BR-DE-17 abgelehnt?

Nein. BR-DE-17 ist eine Warnung: Die Rechnung wird angenommen, der Empfänger sieht aber den Hinweis. Beheben Sie ihn trotzdem, Warnungen werden in späteren Versionen oft zu Fehlern.

Für welche Formate gilt BR-DE-17?

XRechnung in UBL- oder CII-Syntax, einschließlich ZUGFeRD-/Factur-X-PDFs mit dem Profil XRECHNUNG. Rechnungen an deutsche öffentliche Auftraggeber (Bund, Länder, Kommunen) müssen sie bestehen. Syntax: UBL und CII.

Quelle: XRechnung 3.0.2, schematron 2.6.0 (KoSIT, September 2026). Katalog erzeugt aus dem offiziellen Schematron am 2026-10-14.