BR-DE-17
The invoice type code is valid EN 16931 but outside the narrower list XRechnung accepts.
Why it happens
A code such as 386 (prepayment invoice) was used. Legal under EN 16931, discouraged under XRechnung.
How to fix it
Map to the nearest permitted code — usually 380 for a normal invoice, 326 for a partial invoice, 384 for a correction. This is a warning, not a hard failure, but receivers may still reject.
The official rule
XRechnung, official German wordingMit 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).
Our English rendering: Only the following UNTDID 1001 codes should be used in "Invoice type code" (BT-3): 326 (partial invoice), 380 (commercial invoice), 384 (corrected invoice), 389 (self-billed invoice), 381 (credit note), 875, 876, 877 (construction industry).
Technical detail — where the rule is evaluated and the exact test
| Syntax | Context and assertion |
|---|---|
| UBL | /ubl:Invoice | /cn:CreditNote |
normalize-space(cbc:InvoiceTypeCode) = $supportedInvAndCNTypeCodes or normalize-space(cbc:CreditNoteTypeCode) = $supportedInvAndCNTypeCodes | |
| CII | /rsm:CrossIndustryInvoice |
normalize-space(rsm:ExchangedDocument/ram:TypeCode) = ('326', '380', '384', '389', '381', '875', '876', '877') |
Check your own invoice
Paste or drop your UBL or CII file into the free validator. It runs the official EN 16931 ruleset plus the German XRechnung layer and lists every rule that fires, BR-DE-17 included — no signup, no limit.
Validate an e-invoice freeFixing the data at source instead? The CSV converter builds a compliant invoice from a spreadsheet export.