BT-3Invoice type code
Official rule text
[BR-DE-17] Only the following codes from the code list UNTDID 1001 shall be transmitted in the element "Invoice type code" (BT-3): 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).
Official text (German): 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).
Why this error occurs
XRechnung narrows the UNTDID 1001 list: only 326 (partial invoice), 380 (commercial invoice), 384 (corrected invoice), 389 (self-billed invoice), 381 (credit note), 875, 876 and 877 (construction invoices) should be used in BT-3. The rule compares cbc:InvoiceTypeCode / cbc:CreditNoteTypeCode (UBL) or rsm:ExchangedDocument/ram:TypeCode (CII) with that list and raises a warning otherwise. Typical offenders are 386 (prepayment invoice), 383 (debit note) or 82 (metered services), which are valid in EN 16931 but not expected by German authorities.
How to fix it
Map your document types to the allowed codes: regular invoice 380, partial/instalment invoice 326, correction 384, credit note 381 (as cn:CreditNote in UBL), self-billing 389, construction partial/partial-final/final 875/876/877. A down-payment request is normally sent as 380 or 326 with the prepayment shown in the line text; the final invoice then uses BT-113 (prepaid amount) for the amounts already paid. This is a warning, but many receivers treat it as an error.
Example (valid)
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>What the validator checks
Checked element (context):
UBL
/ubl:Invoice | /cn:CreditNoteTest (XPath):
normalize-space(cbc:InvoiceTypeCode) = $supportedInvAndCNTypeCodes or normalize-space(cbc:CreditNoteTypeCode) = $supportedInvAndCNTypeCodesCII
/rsm:CrossIndustryInvoiceTest (XPath):
normalize-space(rsm:ExchangedDocument/ram:TypeCode) = ('326', '380', '384', '389', '381', '875', '876', '877')Check your invoice
Drop your XML or PDF on the validator and every failed rule is linked to its page here. Free, no account, the file is not stored.
Same check via API:
curl -F file=@invoice.xml https://einvoicechecker.com/v1/validateRelated rules
BR-DE-26Corrected invoice (384) without preceding invoice referenceBR-DE-1Payment instructions (BG-16) are missingBR-DE-2Seller contact (BG-6) is missingBR-DE-3Seller city (BT-37) is missingBR-DE-4The element "Seller post code" must be transmittedBR-DE-5Seller contact point (BT-41) is missingBR-DE-6Seller contact telephone number (BT-42) is missingBR-DE-7Seller contact email address (BT-43) is missing
Frequently asked questions
What does BR-DE-17 mean?
BR-DE-17 is a xrechnung rule: Only the following codes from the code list UNTDID 1001 shall be transmitted in the element "Invoice type code" (BT-3): 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).
Will my invoice be rejected because of BR-DE-17?
No. BR-DE-17 is a warning: the invoice is accepted but the recipient sees the notice. Fix it anyway, warnings often become errors in later rule versions.
Which formats does BR-DE-17 apply to?
XRechnung in UBL or CII syntax, including ZUGFeRD / Factur-X PDFs with the XRECHNUNG profile. Invoices to German public authorities (federal, state and municipal) must pass it. Syntax: UBL and CII.
Source: XRechnung 3.0.2, schematron 2.6.0 (KoSIT, September 2026). Catalogue generated from the official schematron on 2026-10-14.