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.
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
Identify invoice purpose
Determine if this is a standard invoice, credit note, or correction
Set valid type code
Use 380 (commercial), 381 (credit), 384 (corrected), 389 (self-billed), or 326 (partial)
Before / After
<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><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
//cac:AccountingSupplierParty/cac:Party/cac:Contact/cbc:TelephoneCode 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
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.