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

Why does BR-DE-17 happen?

Most systems default to 380 (commercial invoice), which is correct. Deviations usually appear on credit notes or construction-industry partial invoices where a custom code was set. More often it is a code that EN 16931 permits through BR-CL-01 and XRechnung does not list — 383 for a debit note, say, or 386 for a prepayment invoice. The invoice is then compliant with the norm and still draws this warning. Both syntaxes check the same eight codes; in the UBL expression they are simply hidden behind the variable name supportedInvAndCNTypeCodes.

What the validator checks

The expression the official KoSIT rule set evaluates — not paraphrased, but read from the Schematron file it ships. UBL and CII address different document trees, so the same rule reads differently in each.

UBL

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

Variables in it

$supportedInvAndCNTypeCodes

('326', '380', '384', '389', '381', '875', '876', '877')

CII

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

Source: rule set v2026-08-31

How do you fix BR-DE-17?

Map your internal document type onto one of the permitted codes — 380 for a normal invoice, 326 for a partial invoice, 381 for a credit note. Of the eight, 381 is the only one BR-CL-01 will not accept in cbc:InvoiceTypeCode in UBL: there it belongs in the cbc:CreditNoteTypeCode of a CreditNote document.

<cbc:InvoiceTypeCode>RE</cbc:InvoiceTypeCode>

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