Validation errors
XRechnung validation errors (BR-DE): how to fix them
An XRechnung that fails validation is rejected by public-sector portals, accounting systems and recipient software — often with no clear message. The most common causes are missing mandatory fields (BR-DE rules), sum rounding errors and a wrong profile ID. This page shows the five most frequent errors with concrete fixes.
What is a BR-DE error?
BR-DE errors are German additional rules (CIUS = Core Invoice Usage Specification) built on top of the European standard EN 16931. They make some optional EN 16931 fields mandatory for Germany. A validator reports them with the prefix BR-DE-NNN. Quick distinction:
- BR-NNN — core EN 16931 rules (e.g. BT-1 invoice number is mandatory).
- BR-DE-NNN — German CIUS additions (e.g. BR-DE-1: seller must provide an electronic endpoint BT-34).
- BR-DEX-NNN — extended German rules.
The 5 most common errors and their fixes
1. BR-DE-1 — Missing seller electronic address (BT-34)
XRechnung requires the seller to provide an electronic endpoint (BT-34) and scheme ID (BT-34-1). It is used for routing in B2G and is still mandatory in B2B.
Error text: BR-DE-1: An invoice must contain the identifier of the seller.
Fix (UBL syntax) — inside cac:AccountingSupplierParty/cac:Party add:
<cbc:EndpointID schemeID="0002">invoice@example.de</cbc:EndpointID>Scheme code 0002 = email address. Other valid codes: 9930 (tax number), 0088 (GLN).
2. BR-DE-15 / BR-DE-16 — Missing payment terms (BT-20)
XRechnung requires at least one of BT-20 (payment terms text) or BT-9 (due date).
Error text: BR-DE-15: Payment terms must be provided when no due date is given.
Fix:
<cac:PaymentTerms>
<cbc:Note>Payment due within 30 days net.</cbc:Note> <!-- BT-20 -->
</cac:PaymentTerms>3. Sum mismatches (BT-106 / BT-109 / BT-112 / BT-115)
The validator checks the full arithmetic chain. Even a one-cent rounding error causes a failure.
- Sum of line amounts (BT-106) = Σ BT-131 (quantity × unit price per line)
- Net total (BT-109) = BT-106 − document-level allowances + document-level charges
- VAT total (BT-110) = Σ BT-117 per VAT rate
- Gross total (BT-112) = BT-109 + BT-110
- Amount due (BT-115) = BT-112 − prepayments (usually = BT-112)
Rule: round each line amount (BT-131) to two decimal places before summing. Never round only at the end.
4. Wrong profile (MINIMUM or BASIC-WL instead of CIUS XRechnung)
If cbc:CustomizationID (BT-24) contains a MINIMUM or BASIC-WL profile, mandatory fields those profiles do not define will be missing and the recipient system will reject the file.
Correct CustomizationID for XRechnung 3.0:
<cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0</cbc:CustomizationID>5. VAT category code inconsistent with VAT rate (BT-118 / BT-119)
Common mismatches:
S(standard) with rate0→ error. UseZfor zero-rated.E(exempt) with rate19→ error. Exempt means 0 % plus a reason code (BT-120).K(intra-EU) orG(export) must always have rate0.
Step-by-step: finding errors systematically
- Run the validator. Upload the file to the free fakturai validator. It shows you the exact BR-DE code, the XML line and an explanation — no account needed.
- Work through the error list. Fix structural errors (missing mandatory fields) first, then calculation errors (sums), then profile errors (CustomizationID).
- Re-validate after each fix. Repeat until the file reaches ACCEPT level, then send.
Check XRechnung for BR-DE errors for free
What fakturai does not replace
fakturai checks technical format and structural compliance per EN 16931 with a KoSIT-aligned accept gate, including BR-DE rules. The content and tax correctness of the invoice, proper archiving and accounting treatment remain your responsibility. fakturai is not tax advice and makes no legal, tax or delivery guarantees.
Next step
Free XRechnung validator (BR-DE included) · Create an API key
Related: E-invoice example (XML) · XRechnung or ZUGFeRD · Validation checklist · Technical validation (KoSIT)