XRechnung BR-DE Validation Errors: The Complete Troubleshooting Guide

If you're integrating XRechnung into your ERP system and hitting BR-DE errors from the KOSIT validator, you're in the right place. This guide covers every German-specific business rule (BR-DE) with the exact cause, the XML fix, and the context you need to ship compliant invoices.

What Are BR-DE Rules?

The European e-invoicing standard EN 16931 defines a core set of business rules (BR-01, BR-02, etc.) that apply across all EU member states. On top of that, each country can define a CIUS (Core Invoice Usage Specification) — a set of additional national rules that constrain or extend the core standard.

Germany's CIUS is called XRechnung, and its country-specific rules use the prefix BR-DE. These rules enforce requirements unique to German tax law and public procurement, such as mandatory payment information, the Leitweg-ID routing code, and seller contact details.

When you validate an invoice with the KOSIT validator or Invoice Navigator's validator, BR-DE errors indicate your invoice violates a German-specific requirement — even if it passes the core EN16931 checks.

Current Versions (as of March 2026)

• XRechnung: 3.0.x
• KOSIT Validator Configuration: 2026-01-31
• KoSIT Validator Engine: v1.6.0
• CEN Schematron Rules: 1.3.15
• Specification Identifier: urn:cen.eu:en16931:2017#compliant#urn:xrechnung:3.0

---

BR-DE Error Reference

BR-DE-1 — Payment Instructions Required

Rule: An invoice MUST contain Payment Instructions (BG-16).

What it means: Every XRechnung invoice must include at least one payment method. This is stricter than the core EN16931 standard, where payment instructions are conditional.

Common causes:

• Missing the entire PaymentMeans block
• Including payment terms (BT-20) without corresponding payment method
• Confusing ZUGFeRD's optional payment handling with XRechnung's mandatory requirement

UBL 2.1 Fix:

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>58</cbc:PaymentMeansCode>
  <cac:PayeeFinancialAccount>
    <cbc:ID>DE89370400440532013000</cbc:ID>
    <cbc:Name>Seller Account</cbc:Name>
    <cac:FinancialInstitutionBranch>
      <cbc:ID>COBADEFFXXX</cbc:ID>
    </cac:FinancialInstitutionBranch>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

CII Fix:

<ram:SpecifiedTradeSettlementPaymentMeans>
  <ram:TypeCode>58</ram:TypeCode>
  <ram:PayeePartyCreditorFinancialAccount>
    <ram:IBANID>DE89370400440532013000</ram:IBANID>
  </ram:PayeePartyCreditorFinancialAccount>
  <ram:PayeeSpecifiedCreditorFinancialInstitution>
    <ram:BICID>COBADEFFXXX</ram:BICID>
  </ram:PayeeSpecifiedCreditorFinancialInstitution>
</ram:SpecifiedTradeSettlementPaymentMeans>

Payment means codes: 30 = credit transfer, 58 = SEPA credit transfer, 59 = SEPA direct debit, 48 = bank card. Use 58 for standard German business invoicing.

---

BR-DE-2 — Buyer Reference or Purchase Order Reference Required

Rule: The element "Buyer reference" (BT-10) MUST be provided.

What it means: For German public sector invoices, BT-10 typically carries the Leitweg-ID — the routing identifier that tells the receiving platform (like ZRE or OZG-RE) where to deliver the invoice. For B2B invoices, this field still must be present but can contain an internal reference.

Common causes:

• Omitting BuyerReference entirely
• Placing the Leitweg-ID in the wrong field (e.g., in OrderReference instead of BuyerReference)
• Using an outdated XRechnung version where this field had different cardinality

UBL 2.1 Fix:

<!-- For public sector invoices, use the Leitweg-ID -->
<cbc:BuyerReference>04011000-1234512345-06</cbc:BuyerReference>

<!-- For B2B invoices without a Leitweg-ID -->
<cbc:BuyerReference>INTERNAL-REF-2026-001</cbc:BuyerReference>

CII Fix:

<ram:ApplicableHeaderTradeAgreement>
  <ram:BuyerReference>04011000-1234512345-06</ram:BuyerReference>
  <!-- ... -->
</ram:ApplicableHeaderTradeAgreement>

What is a Leitweg-ID? It's a structured routing code in the format [Grobadressat]-[Feinadressat]-[Prüfziffer], used by German public authorities to route incoming invoices to the correct department. You receive it from the contracting authority. See our glossary entry on Leitweg-ID for the full format specification.

---

BR-DE-3 — Seller Contact Telephone Required

Rule: The element "Seller contact telephone number" (BT-42) MUST be provided.

What it means: XRechnung requires a telephone number for the seller's contact person. The core EN16931 standard makes this optional.

UBL 2.1 Fix:

<cac:AccountingSupplierParty>
  <cac:Party>
    <cac:Contact>
      <cbc:Name>Rechnungsabteilung</cbc:Name>
      <cbc:Telephone>+49 30 123456789</cbc:Telephone>
      <cbc:ElectronicMail>rechnung@example.de</cbc:ElectronicMail>
    </cac:Contact>
    <!-- ... -->
  </cac:Party>
</cac:AccountingSupplierParty>

---

BR-DE-4 — Seller Contact Email Required

Rule: The element "Seller contact email address" (BT-43) MUST be provided.

What it means: Like telephone, the email for the seller's contact person is mandatory in XRechnung. Both BT-42 (phone) and BT-43 (email) must be present.

Fix: Ensure the <cbc:ElectronicMail> element exists within the seller's <cac:Contact> block (see BR-DE-3 example above).

---

BR-DE-5 — Seller Contact Name Required

Rule: The element "Seller contact point" (BT-41) MUST be provided.

What it means: XRechnung requires a named contact person or department for the seller. This trio — name (BT-41), phone (BT-42), and email (BT-43) — is always required together.

Fix: Ensure <cbc:Name> exists within the seller's <cac:Contact> block. Use a department name if no individual contact is appropriate (e.g., "Rechnungswesen" or "Accounts Department").

---

BR-DE-6 — Seller City Required

Rule: The element "Seller city" (BT-37) MUST be provided.

Common cause: Omitting the city from the seller's postal address. This is easy to miss when generating invoices from incomplete address records.

UBL 2.1 Fix:

<cac:PostalAddress>
  <cbc:StreetName>Musterstraße 1</cbc:StreetName>
  <cbc:CityName>Berlin</cbc:CityName>
  <cbc:PostalZone>10115</cbc:PostalZone>
  <cac:Country>
    <cbc:IdentificationCode>DE</cbc:IdentificationCode>
  </cac:Country>
</cac:PostalAddress>

---

BR-DE-7 — Seller Post Code Required

Rule: The element "Seller post code" (BT-38) MUST be provided.

Fix: Include <cbc:PostalZone> (UBL) or <ram:PostcodeCode> (CII) in the seller's postal address.

---

BR-DE-8 — Buyer City Required

Rule: The element "Buyer city" (BT-52) MUST be provided.

Fix: Same as BR-DE-6 but for the buyer's address. Ensure <cbc:CityName> exists in <cac:AccountingCustomerParty>.

---

BR-DE-9 — Buyer Post Code Required

Rule: The element "Buyer post code" (BT-53) MUST be provided.

Fix: Include <cbc:PostalZone> in the buyer's postal address block.

---

BR-DE-10 — Deliver-To City Required (Conditional)

Rule: If delivery information is provided, the element "Deliver to city" (BT-77) MUST be provided.

Common cause: Including a <cac:Delivery> block with a partial address. If you include delivery information at all, the city must be present.

Fix: Either omit the <cac:Delivery> block entirely, or include a complete address with city.

---

BR-DE-11 — Deliver-To Post Code Required (Conditional)

Rule: If delivery information is provided, the element "Deliver to post code" (BT-78) MUST be provided.

Fix: Same logic as BR-DE-10 — if delivery address exists, postal code must be included.

---

BR-DE-13 — Payment Account Required for Credit Transfer

Rule: If payment means code is 58 (SEPA credit transfer) or 30 (credit transfer), a payment account (BT-84) MUST be provided.

Common cause: Including the payment means code without the corresponding IBAN.

Fix: Always pair payment means code 58 or 30 with a <cac:PayeeFinancialAccount> containing the IBAN.

---

BR-DE-14 — VAT Category Rate Required

Rule: The element "VAT category rate" (BT-119) MUST be provided for all VAT categories.

Common cause: Omitting the tax percent when using VAT category codes like "S" (standard rate) or "AE" (reverse charge).

UBL 2.1 Fix:

<cac:TaxCategory>
  <cbc:ID>S</cbc:ID>
  <cbc:Percent>19.00</cbc:Percent>
  <cac:TaxScheme>
    <cbc:ID>VAT</cbc:ID>
  </cac:TaxScheme>
</cac:TaxCategory>

Note: Even for reverse charge (AE) or exempt (E) categories, you must include <cbc:Percent>0.00</cbc:Percent>.

---

BR-DE-15 — Buyer Reference Must Be Transmitted

Rule: The element "Buyer reference" (BT-10) MUST be transmitted.

What it means: This is closely related to BR-DE-2 but enforces that BT-10 must not be empty. A whitespace-only or zero-length string will trigger this error.

Fix: Ensure <cbc:BuyerReference> contains actual content, not just whitespace.

---

BR-DE-16 — Electronic Address Required for Seller

Rule: The element "Seller electronic address" (BT-34) MUST be provided.

What it means: XRechnung 3.0 requires both seller and buyer to have an electronic address (email or Peppol participant ID) specified at the party level.

UBL 2.1 Fix:

<cac:AccountingSupplierParty>
  <cac:Party>
    <cbc:EndpointID schemeID="EM">rechnung@example.de</cbc:EndpointID>
    <!-- For Peppol participants, use schemeID="0204" -->
    <!-- <cbc:EndpointID schemeID="0204">9930:DE123456789</cbc:EndpointID> -->
    <!-- ... -->
  </cac:Party>
</cac:AccountingSupplierParty>

Scheme IDs: EM = email address, 0204 = Peppol participant (Leitweg-ID), 0088 = EAN/GLN. For most German invoices, EM with an email address is the simplest option.

---

BR-DE-17 — Electronic Address Required for Buyer

Rule: The element "Buyer electronic address" (BT-49) MUST be provided.

Fix: Same as BR-DE-16 but for <cac:AccountingCustomerParty>. Include <cbc:EndpointID> with the appropriate scheme.

---

BR-DE-18 — Specification Identifier Must Match

Rule: The specification identifier (BT-24) MUST have the value urn:cen.eu:en16931:2017#compliant#urn:xrechnung:3.0.

Common causes:

• Using a ZUGFeRD specification identifier instead of XRechnung
• Referencing XRechnung 2.x when you should be using 3.0
• Typos in the URN string

UBL 2.1 Fix:

<cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:xrechnung:3.0</cbc:CustomizationID>

CII Fix:

<rsm:ExchangedDocumentContext>
  <ram:GuidelineSpecifiedDocumentContextParameter>
    <ram:ID>urn:cen.eu:en16931:2017#compliant#urn:xrechnung:3.0</ram:ID>
  </ram:GuidelineSpecifiedDocumentContextParameter>
</rsm:ExchangedDocumentContext>

Version history: XRechnung 2.0 used urn:xoev-de:kosit:xrechnung_2.0, XRechnung 2.1+ used urn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard:xrechnung_2.1, and 3.0 uses the current URN. If you're migrating, this is a required change.

---

BR-DE-19 through BR-DE-26 — Payment Means Code Restrictions

These rules constrain which payment means codes are allowed in XRechnung. Not all EN16931 payment codes are valid.

Allowed codes in XRechnung:

Code	Meaning
10	Cash
30	Credit transfer (non-SEPA)
48	Bank card
49	Direct debit (non-SEPA)
57	Standing agreement
58	SEPA credit transfer
59	SEPA direct debit

Common cause: Using code 1 (not defined), 31 (debit transfer), or other codes valid in generic EN16931 but not in XRechnung.

---

BR-DE-29 — Sub-Invoice Lines Not Allowed

Rule: Sub-invoice lines (BG-25 within BG-25) are NOT permitted in XRechnung UBL format.

What it means: While UBL 2.1 technically supports nested invoice lines, XRechnung prohibits them. Each line item must be a flat, top-level entry.

Common cause: ERP systems that model line items hierarchically (e.g., a service with sub-components) and export that hierarchy directly to UBL.

Fix: Flatten your line items. If you need to show hierarchy, use the <cbc:Note> field on line items or the invoice-level note.

---

Debugging Workflow

When you hit a BR-DE error, follow this process:

1. Identify the rule: The validator output includes the rule ID (e.g., [BR-DE-1]) and usually the XPath location of the problem.

2. Check the business term: Each BR-DE rule references a specific EN16931 business term (BT-xx or BG-xx). Look up the term in the EN16931 business terms reference to understand what data is expected.

3. Verify the XML path: The business term maps to a specific XML element depending on whether you're using UBL 2.1 or CII syntax. The mapping differs between syntaxes.

4. Validate incrementally: Fix one error at a time and re-validate. Some errors cascade — fixing a missing PaymentMeans block (BR-DE-1) might also resolve BR-DE-13.

5. Test against the right version: Make sure your validator configuration matches your XRechnung version. Using a 3.0 validator against a 2.1 invoice (or vice versa) will produce false errors.

Quick Validation

Upload your invoice to Invoice Navigator's validator for instant feedback. The validator auto-detects UBL vs. CII syntax and applies the correct XRechnung rules, including all BR-DE checks.

---

Common Migration Pitfalls: XRechnung 2.x → 3.0

If you're upgrading from XRechnung 2.x to 3.0, watch for these breaking changes:

Specification identifier changed: Update BT-24 from the 2.x URN to urn:cen.eu:en16931:2017#compliant#urn:xrechnung:3.0.

Electronic addresses now mandatory: BT-34 (seller) and BT-49 (buyer) electronic addresses were optional in some 2.x scenarios; they're always required in 3.0.

Stricter payment means codes: The allowed set was tightened. Verify your payment codes against the table in BR-DE-19.

Updated CEN schematron: The underlying EN16931 rules also changed between versions. Some invoices that passed 2.x validation may fail 3.0 due to tighter core rules (not just BR-DE rules).

---

XRechnung vs. ZUGFeRD: Which BR Rules Apply?

This is a common source of confusion. Here's how it works:

XRechnung is a CIUS of EN16931 with strict BR-DE rules. If your CustomizationID says urn:xrechnung:3.0, all BR-DE rules apply.

ZUGFeRD/Factur-X uses different profiles (Minimum, Basic, EN16931, Extended). The EN16931 profile applies core EN16931 rules but NOT the BR-DE rules. However, if you use ZUGFeRD with the XRechnung extension profile, BR-DE rules do apply.

Bottom line: BR-DE errors only fire when the specification identifier claims XRechnung compliance. If you're generating ZUGFeRD EN16931 invoices for non-German recipients, these rules don't apply. But for German public sector invoicing, XRechnung (and thus BR-DE rules) is mandatory.

---

FAQ

Why does my invoice pass EN16931 validation but fail XRechnung validation?

Because XRechnung adds country-specific requirements on top of EN16931. Fields that are optional in EN16931 (like seller contact details or buyer reference) become mandatory in XRechnung. The BR-DE rules are the delta between generic EU compliance and German compliance.

Do BR-DE rules apply to B2B invoices?

Yes, starting January 1, 2025, all businesses in Germany must be able to receive XRechnung-compliant invoices. From January 1, 2027, large companies (turnover over EUR 800,000) must also issue them. By 2028, all companies must issue compliant e-invoices. BR-DE rules apply to all XRechnung invoices regardless of B2G or B2B context.

What is the Leitweg-ID and where do I get it?

The Leitweg-ID is a routing identifier for German public sector invoices, placed in BT-10 (Buyer reference). It follows the format [Grobadressat]-[Feinadressat]-[Prüfziffer]. You receive it from the contracting authority as part of the procurement process. For B2B invoices, BT-10 still must be present but can contain any reference string.

Can I use the KOSIT validator locally?

Yes. The KOSIT validator is open-source and available on GitHub. You can run it as a Java CLI tool or integrate it into your CI/CD pipeline. For a faster workflow, use Invoice Navigator's online validator which wraps the same rule set with instant results.

Which schematron version should I use?

As of March 2026, use the Validator Configuration release 2026-01-31, which includes CEN Schematron Rules 1.3.15 and is compatible with XRechnung 3.0.x. Check the KOSIT GitHub releases page for the latest version.

How do BR-DE rules differ from BR-FR or BR-IT rules?

Each EU country can define its own CIUS with country-specific rules. France uses BR-FR rules for Factur-X compliance, Italy has specific FatturaPA requirements for the SDI system, and Belgium requires Peppol BIS 3.0 formatting. These country-specific rules don't overlap — BR-DE only applies to invoices claiming XRechnung compliance. See our country-specific e-invoicing guides for requirements by jurisdiction.

---

Further Reading

• Invoice Navigator Validator — Validate your XRechnung invoices instantly
• E-Invoice Error Library — Complete reference for EN16931 core errors (BR-01 through BR-CO-25)
• What Is Peppol? — Understanding the EU e-invoicing network
• EU E-Invoicing Deadlines — Complete 2025–2030 timeline by country
• EN16931 Business Terms Glossary — Field-by-field reference for the European core invoice