BR-DE-17: Invoice Type Code Not Accepted by XRechnung, the Rule Explained

What BR-DE-17 checks

BR-DE-17 restricts the invoice type code, BT-3: in UBL cbc:InvoiceTypeCode (or cbc:CreditNoteTypeCode), in CII rsm:ExchangedDocument/ram:TypeCode. EN 16931 allows any credible UNTDID 1001 code; the German CIUS narrows the list to eight codes with defined processing semantics in public-sector workflows: 326, 380, 381, 384, 389, 875, 876 and 877. The rule is a should-level constraint (KoSIT flags it as a warning), but German intake platforms are built around exactly these types.

Layer and formats

The finding carries "layer": "cius" and fires when validating against the XRechnung profile: UBL, CII, and ZUGFeRD / Factur-X hybrids declaring the XRechnung CustomizationID. Because KoSIT marks it flag="warning", the finding appears in the report's warnings; a document can pass with it, but should not ship with it.

Why it fails in practice

ERP type codes passed through unmapped. Source systems use the full UNTDID vocabulary (383 debit note, 386 prepayment invoice, 393 factored invoice), which XRechnung does not accept.
Credit notes with the wrong code. A credit is exported as 261 (self billed credit note) or another credit variant instead of the accepted 381.
Construction invoices guessed. The sector-specific codes 875 to 877 exist precisely for German construction billing; pipelines unaware of them fall back to codes the rule rejects.

How to fix it

Map your document types onto the accepted eight before generating, with 380 as the default:

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

In an InvoiceXML create request the field is invoice.typeCode; leave it unset and POST /v1/create/xrechnung stamps 380 for you.

The raw rejection vs the InvoiceXML finding

The Schematron report quotes the German rule with the whole code list inline:

<svrl:failed-assert id="BR-DE-17" flag="warning"
    location="/*:Invoice[namespace-uri()='urn:oasis:names:specification:ubl:schema:xsd:Invoice-2'][1]">
  <svrl:text>[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).</svrl:text>
</svrl:failed-assert>

The InvoiceXML finding for the same failure:

{
  "rule": "BR-DE-17",
  "layer": "cius",
  "line": null,
  "message": "The invoice type code is not accepted by XRechnung. Use one of the UNTDID 1001 codes 326, 380, 381, 384, 389, 875, 876 or 877.",
  "btCodes": ["BT-3"],
  "fields": ["typeCode"],
  "raw": "[BR-DE-17] CIUS: 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), ..."
}

One readable sentence with the accepted codes, mapped to the exact request field, instead of a German paragraph to parse and translate for your end customers. Clients localize by the stable rule key and keep the field mapping.

Check or generate XRechnung documents

Validate a file in the XRechnung validator to see warnings and errors separated by layer, or generate with POST /v1/create/xrechnung, which defaults BT-3 to 380 and validates before delivery. The XRechnung API toolkit covers the full integration.

BR-DE-18, the neighbouring format rule for Skonto payment terms
BR-DE-15, the mandatory buyer reference (Leitweg-ID)
BR-DE-21, the specification identifier must be the XRechnung one
The XRechnung 3.0 CustomizationID, the identifier that activates the BR-DE rules

Frequently asked questions

Which type codes does XRechnung accept?

326 (partial invoice), 380 (commercial invoice), 381 (credit note), 384 (corrected invoice), 389 (self-billed invoice), and the construction-sector trio 875 (partial construction invoice), 876 (partial final construction invoice) and 877 (final construction invoice). Everything else in UNTDID 1001 triggers BR-DE-17.

What should a normal invoice use?

380. It is the default commercial invoice code, and the InvoiceXML create endpoints stamp it automatically when you do not set a type code. Reach for the other codes only when the business case genuinely matches them.

Is BR-DE-17 a hard rejection?

KoSIT flags it as a warning ('sollen', should), so validation reports list it among warnings rather than fatal errors. Treat it as binding anyway: German receiving platforms and downstream workflows are built around the eight codes, and exotic types cause manual clarification even where intake succeeds.

My system sends 383 (debit note) or 386 (prepayment invoice). What now?

Map them before export: most debit-note cases are corrected invoices (384) or ordinary invoices (380) in XRechnung terms, and prepayment requests are typically partial invoices (326). The mapping is a business decision; the constraint is that BT-3 must land on one of the eight accepted codes.

BR-DE-17