BR-DE-17 — E-Invoice Validation Rule & Fix

Fixture ID: badInvoiceType · XPath: /ubl:Invoice/cbc:InvoiceTypeCode

1. Why This Rule Triggers (Diagnostic Message)

XRechnung asks that the invoice type code (BT-3) be one of 326, 380, 381, 384, 389, 875, 876 and 877 from UNTDID 1001, but "999" was supplied. The rule is one rule across both document types: KoSIT's schematron tests `cbc:InvoiceTypeCode = $supportedInvAndCNTypeCodes or cbc:CreditNoteTypeCode = $supportedInvAndCNTypeCodes`, against one eight-code list, so a credit note is held to exactly the same eight. The German text says "sollen", and KoSIT flags the rule "warning" rather than "fatal": the document is accepted, and the wider UNTDID list stays legal under core EN 16931. Treat it as a portal-compatibility finding rather than a rejection — a receiving system that only branches on the eight listed codes will not know what to do with yours, which is a slower and more expensive failure than a bounce.

2. How to Fix BR-DE-17

Use "380" for a commercial invoice, "384" for a corrected invoice (and then also supply precedingInvoices with the number of the invoice you are correcting, BR-DE-26), "326" for a partial invoice, "389" for self-billing, "381" for a credit note. All eight generate: "381" and the rest of the UNTDID 1001 credit-note list emit a ubl:CreditNote in the UBL syntax and a CrossIndustryInvoice with ram:TypeCode 381 in CII.

3. Valid Code / Payload Example

"invoiceTypeCode": "380"