errorbusinessDEUXRechnung (Germany)

BR-DE-17:Seller contact information (name, phone, email) required in XRechnung

Fix: Step 1: Locate cac:AccountingSupplierParty/cac:Party in the Invoice or CreditNote. Step 2: Make sure a cac:Contact child exists. If not, create one — its position is after cac:PartyTaxScheme and before cac:PartyLegalEntity in UBL 2.1 canonical order. Step 3: Populate the three required children: • `<cbc:Name>Accounts Receivable</cbc:Name>` — a department, role or person name (BT-41). • `<cbc:Telephone>+49 30 1234567</cbc:Telephone>` — a usable phone number, with country code recommended (BT-42). • `<cbc:ElectronicMail>invoicing@example.de</cbc:ElectronicMail>` — a monitored email address (BT-43). Step 4: Validate each value: • Name must be a non-empty string with no leading/trailing whitespace. • Telephone should be at least 5 characters; many validators accept any digits and `+ - ( ) space` but reject letters. • Email must contain exactly one `@`, a non-empty local part and a domain with at least one dot. Use a deliverable address — the buyer's accounts payable team uses it to query the invoice. Step 5: Do not put contact data under cac:PartyContact (deprecated). The KoSIT validator only checks cac:Contact. Step 6: Re-validate against the KoSIT XRechnung 2.x or 3.x ruleset. BR-DE-17 should clear, and BR-DE-18 (cbc:ElectronicMail required) and BR-DE-19 (cbc:Telephone required) — its sibling rules — should also pass. Provide the required value in the free validator.

BR-DE-17 fires when an XRechnung invoice's seller party (cac:AccountingSupplierParty/cac:Party) does not carry a complete cac:Contact block containing the seller contact point name (BT-41, cbc:Name), telephone (BT-42, cbc:Telephone) and email (BT-43, cbc:ElectronicMail). XRechnung makes all three contact fields mandatory; Peppol BIS Billing 3.0 makes them optional, so an invoice that validates against Peppol can still fail KoSIT XRechnung validation with BR-DE-17.

Severity
Fatal
Rule set
XRechnung (Germany)
Country
DEU
Fix type
INPUT REQUIRED
Confidence
40%
Category
structural

Engine Classification

Business data required · Explicit input workflow · No assumptions made

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 rejected by Peppol access points and never reaches the buyer.

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

Why This Error Matters

Invoice rejected. German XRechnung only processes recognized document types.

BR-DE-17 is a hard failure — the invoice must be corrected and re-sent before it can reach the recipient.

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:AccountingSupplierParty>
  <cac:Party>
    <cac:PartyName><cbc:Name>Muster GmbH</cbc:Name></cac:PartyName>
    <cac:PostalAddress>...</cac:PostalAddress>
    <cac:PartyTaxScheme>
      <cbc:CompanyID>DE123456789</cbc:CompanyID>
      <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
    </cac:PartyTaxScheme>
    <cac:PartyLegalEntity><cbc:RegistrationName>Muster GmbH</cbc:RegistrationName></cac:PartyLegalEntity>
    <!-- cac:Contact missing -->
  </cac:Party>
</cac:AccountingSupplierParty>
Corrected XML
<cac:AccountingSupplierParty>
  <cac:Party>
    <cac:PartyName><cbc:Name>Muster GmbH</cbc:Name></cac:PartyName>
    <cac:PostalAddress>...</cac:PostalAddress>
    <cac:PartyTaxScheme>
      <cbc:CompanyID>DE123456789</cbc:CompanyID>
      <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
    </cac:PartyTaxScheme>
    <cac:PartyLegalEntity><cbc:RegistrationName>Muster GmbH</cbc:RegistrationName></cac:PartyLegalEntity>
    <cac:Contact>
      <cbc:Name>Accounts Receivable</cbc:Name>
      <cbc:Telephone>+49 30 1234567</cbc:Telephone>
      <cbc:ElectronicMail>invoicing@muster.de</cbc:ElectronicMail>
    </cac:Contact>
  </cac:Party>
</cac:AccountingSupplierParty>

Technical Reference

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

Code Example

The 'before' party has all the mandatory EN 16931 fields (name, address, tax ID, legal entity) but no cac:Contact, so Peppol validates while KoSIT XRechnung fails BR-DE-17. The 'after' adds the cac:Contact block with all three required children (BT-41, BT-42, BT-43). The element must come after cac:PartyLegalEntity in canonical UBL order or schematron errors about element ordering may appear.

Common Causes

  • ·Common failure modes: (1) cac:Contact is missing entirely under the seller party — the source system never collects a contact for invoicing purposes. (2) cac:Contact exists but one of cbc:Name, cbc:Telephone, cbc:ElectronicMail is missing. The KoSIT schematron requires all three. (3) cbc:ElectronicMail contains an invalid value like 'noreply' (no @ sign) or whitespace. (4) cbc:Telephone is a free-text field with characters the validator does not accept (some validators enforce E.164-ish formats). (5) The invoice declares the Peppol BIS customisation but is sent to a German public-sector recipient that expects XRechnung — the KoSIT layer adds BR-DE-17 on top of EN 16931 and the rule fires. (6) Contact details are written under cac:PartyContact (the deprecated UBL element) instead of cac:Contact.

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

Frequently Asked Questions

The seller party in your invoice is missing the cac:Contact block, or the block does not contain all three required children: cbc:Name (BT-41), cbc:Telephone (BT-42) and cbc:ElectronicMail (BT-43). XRechnung makes these mandatory even though Peppol BIS Billing 3.0 leaves them optional.

Partially. We can detect the missing cac:Contact block, validate any partial values, and inject a configured fallback contact (e.g. a default invoicing email + phone from the supplier's onboarding settings) if the source data is missing. Confidence is 0.4 — surfacing the data is preferable to defaulting, because the contact appears on the printed invoice.

cac:Contact is the modern UBL 2.1 element under cac:Party used by EN 16931 and XRechnung. cac:PartyContact is a deprecated location some legacy systems still write to. The KoSIT validator only checks cac:Contact, so BR-DE-17 fires even if data is present in cac:PartyContact.

Fatal — it has severity 'error' in the KoSIT XRechnung schematron. An invoice that fails BR-DE-17 is rejected by German public-sector receiving systems like ZRE (Zentrale Rechnungseingangsplattform Bund) and OZG-RE. The invoice cannot be posted until the contact is provided.

Related Errors

Related Content

Last updated: 26 May 2026

Share this guide:

Validate your invoice

Drop your XML here to check for BR-DE-17

Fix BR-DE-17 with guided input

Upload your invoice and we'll ask for the missing data, then apply a safe, auditable fix.