Fix BR-DE-17: Invalid invoice type code (BT-3)

What does BR-DE-17 mean?

The element "Invoice type code" (BT-3) should carry only the following codes from code list UNTDID 1001: 326 (Partial invoice), 380 (Commercial invoice), 384 (Corrected invoice), 389 (Self-billed invoice) and 381 (Credit note), 875 (Partial construction invoice), 876 (Partial final construction invoice), 877 (Final construction invoice). The rule comes from KoSIT (XRechnung) and is a warning: the invoice stays valid.

Common causes of BR-DE-17

• A prepayment invoice carries code 386. XRechnung does not recommend the code but allows it; the warning is then acceptable.
• Another code from UNTDID 1001 is in BT-3, for example 383 (debit note) or 393 (factored invoice).
• Transposed digits, for example 830 instead of 380. If the code is not in the list at all, BR-CL-1 appears as well.

How to fix BR-DE-17

1. Find the faulty spot in the XML. Open the XML of the invoice and go to field BT-3 along this XPath://rsm:ExchangedDocument/ram:TypeCode
2. Apply the fix. Use only permitted UNTDID 1001 codes for the invoice type (BT-3): 326, 380, 384, 389, 381, 875, 876, 877. On a prepayment invoice (386) the warning is acceptable: XRechnung does not recommend the code, but it allows it. To avoid the warning, use 326 (partial invoice).
3. Validate again. Save the file and validate it again to check that BR-DE-17 is no longer reported.

Frequent questions about BR-DE-17

Related error codes

Check BR-DE-17 automatically

Instead of digging through the XML by hand you can validate your ZUGFeRD or XRechnung file online: upload the PDF or the XML and you get every error with rule ID, affected field, fix and XPath, as a readable report or as JSON through the API.