Why does my XRechnung invoice fail with BR-DE-17?

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.

Can Invoice Navigator auto-fix BR-DE-17?

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.

What is the difference between cac:Contact and cac:PartyContact?

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.

Is BR-DE-17 a fatal error or just a warning?

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.

Error codes · XRechnung · Germany

BR-DE-17In your invoicing software

Seller contact information (name, phone, email) required in XRechnung

This is the rejection, word for word: „[BR-DE-17] 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.“

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.

What to have readyNothing. The file has to be re-exported from your invoicing software; we check it again afterwards.

What we doStep 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.

Choose the rejected invoiceor drop it here

XRechnung XML or ZUGFeRD PDF. Checking is free · corrected file €1.90 · the first every 30 days is free · no sign-up.

If you enter it yourself in your invoicing software

Before

<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>

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>
      <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>

Element order is part of the rule: if the element sits in the wrong place, the validator rejects with BR-DE-17.

What the finding looks likeExample

FindingStructure invalid · BR-DE-17

Location//cac:AccountingSupplierParty/cac:Party/cac:Contact/cbc:Telephone

From youA re-exported file

ThenRe-export

ProofSHA-256 and /verify link after the check

Often appears together with

BR-DE-18Invalid Skonto (Cash Discount) Format