errorDEUXRechnung (Germany)

BR-DE-17:Invalid XRechnung Invoice Type Code

XRechnung only allows specific Invoice Type Codes: 326 (partial), 380 (commercial), 381 (credit note), 384 (corrected), 389 (self-billed), 875-877 (construction invoices).

Severity
Fatal
Rule set
XRechnung (Germany)
Country
DEU
Fix type
AUTO-FIX
Confidence
80%
Category
structural

Engine Classification

Ensure seller contact telephone is present for XRechnung compliance

Confidence: 80% · Applied automatically in pipeline

What is BR-DE-17?

BR-DE-17 is a fatal validation rule defined in the XRechnung (Germany) specification (DEU national rules). It validates the Telephone element under Party > Contact in the UBL invoice XML.

When this rule fires, the invoice is non-compliant and will be rejected by Peppol access points and national validation services. The sending system receives a rejection response and the invoice does not reach the buyer.

Target path: //cac:AccountingSupplierParty/cac:Party/cac:Contact/cbc:Telephone

Get API AccessTest This Error ↓

Why This Error Matters

Invoice rejected. German XRechnung only processes recognized document types.

BR-DE-17 is a hard failure. Invoices that trigger this rule are rejected at the access point and never reach the recipient. In Peppol networks, this means your sending system receives an MLR (Message Level Response) with a rejection status. The invoice must be corrected and re-sent, adding delay to your payment cycle.

Invoice Navigator can automatically correct this error in your pipeline. The fix is applied with full audit evidence, so your compliance trail remains intact.

Validator Behavior

  • ·Causes invoice rejection
  • ·Rejected by XRechnung endpoints
  • ·Error returned: BR-DE-17
  • ·Specification: XRechnung (Germany)

How to Fix It

1.

Identify invoice purpose

Determine if this is a standard invoice, credit note, or correction

2.

Set valid type code

Use 380 (commercial), 381 (credit), 384 (corrected), 389 (self-billed), or 326 (partial)

Before / After

Failing XML
<cac:PartyTaxScheme>
  <cbc:CompanyID>INVALID_CODE</cbc:CompanyID>
</cac:PartyTaxScheme>
Corrected XML
<cac:PartyTaxScheme>
  <cbc:CompanyID>VALID_CODE</cbc:CompanyID>
</cac:PartyTaxScheme>

Technical Reference

XPath//cac:AccountingSupplierParty/cac:Party/cac:Contact/cbc:Telephone
SpecXRechnung (Germany)
Operationset_default
StrategyEnsure seller contact telephone is present for XRechnung compliance

Common Causes

  • ·Invalid invoice type code for XRechnung
  • ·BT-3 uses code not allowed in German invoices
  • ·Only 326/380/384/389/381/875/876/877 permitted
  • ·Legacy invoice type code not mapped to German subset
  • ·Construction invoice codes not properly assigned

Seeing this in production? The API handles BR-DE-17 automatically. See the fix response →

Frequently Asked Questions

XRechnung only accepts specific UNTDID 1001 codes: 326 (partial), 380 (commercial), 381 (credit note), 384 (corrected), 389 (self-billed), 875-877 (construction).

Change the InvoiceTypeCode to a valid value. Use 380 for standard invoices, 381 for credit notes, 384 for corrections.

Yes, BR-DE-17 will cause invoice rejection by German public authorities. The type code must be corrected.

Yes, Invoice Navigator can automatically map invalid type codes to the nearest valid XRechnung code.

Related Errors

BR-DE-18

Invalid Skonto (Cash Discount) Format

Last updated: 27 February 2026

Share this guide:

Handle BR-DE-17 Automatically in Your Pipeline

The compliance engine auto-remediates this error with controlled safety policies and evidence pack generation.

Get API AccessView API Documentation