How to Fix the 10 Most Common XRechnung Validation Errors

Most XRechnung validation errors come from three sources: mandatory fields required by the German business rules (BR-DE) are missing, totals break the EN 16931 calculation rules, or the specification identifier in BT-24 is wrong. Every error message names a rule ID such as BR-DE-15 and usually a business term (BT). Together they point to the XML element to fix.

Last reviewed: September 2026. Based on XRechnung 3.0.2 and the KoSIT validator configuration for XRechnung 3.0.2. This article is general information, not tax advice.

How is an XRechnung error message structured?

An XRechnung is validated in three stages. First, the XML schema (XSD) of UBL 2.1 or UN/CEFACT CII checks the technical structure. Next come the Schematron rules of the European standard EN 16931, and finally the national XRechnung rules published by KoSIT, the German coordination office for IT standards. The official rule files are public in the KoSIT validator configuration on GitHub (opens in a new tab).

Each rule has a flag. Violations flagged 'fatal' make the KoSIT validator recommend 'reject'. Violations flagged 'warning' are reported, but the recommendation stays 'accept'. The German rules are worded in German, for example [BR-DE-15] Das Element "Buyer reference" (BT-10) muss übermittelt werden. ('The element Buyer reference must be provided.') Reports often write EN rules with a leading zero (BR-02 instead of BR-2). Our reference of xrechnung validation errors explains each code.

The 10 most common XRechnung errors at a glance

Errors 1 to 10: cause and fix

1. BR-DE-15: buyer reference (BT-10) missing

BR-DE-15 means the 'Buyer reference' field is missing or empty. BT-10 is mandatory in every XRechnung. For public buyers it holds the Leitweg-ID (the routing ID of the receiving authority). In B2B, any reference from the buyer works: a purchase order number, a cost centre or the name of the person who ordered. The cause is nearly always an empty field in the customer master data.

Fix: fill cbc:BuyerReference directly under the UBL root element, or ram:ApplicableHeaderTradeAgreement/ram:BuyerReference in CII. The Leitweg-ID comes from the contracting authority; our guide on how to get a Leitweg-ID explains where to find it. The KoSIT rules do not check its check digit, but the federal OZG-RE platform does and otherwise reports 'Leitweg-ID ist nicht valide' (Leitweg-ID not valid), often because of misplaced hyphens or spaces. Our leitweg id validator catches that before you send.

2. BR-DE-2, BR-DE-5 to BR-DE-7: seller contact incomplete

BR-DE-2 requires the SELLER CONTACT group (BG-6). Three fields in it are mandatory: contact point BT-41 (BR-DE-5), telephone BT-42 (BR-DE-6) and email BT-43 (BR-DE-7). EN 16931 does not require them, so many exports leave them out.

Fix: in UBL, put the values under cac:AccountingSupplierParty/cac:Party/cac:Contact in cbc:Name, cbc:Telephone and cbc:ElectronicMail. In CII, use ram:SellerTradeParty/ram:DefinedTradeContact with ram:PersonName, ram:TelephoneUniversalCommunication/ram:CompleteNumber and ram:EmailURIUniversalCommunication/ram:URIID. A department such as 'Accounts' is fine as the contact point, and a shared mailbox is fine as the email. Two warnings check the format: BR-DE-27 expects at least three digits in the phone number and BR-DE-28 exactly one @ in the email address.

3. BR-DE-3, BR-DE-4, BR-DE-8, BR-DE-9: city or post code missing

EN 16931 only requires the country code in an address. XRechnung also requires city and post code for the seller (BR-DE-3 for BT-37, BR-DE-4 for BT-38) and the buyer (BR-DE-8 for BT-52, BR-DE-9 for BT-53). If you add a separate delivery address, BR-DE-10 and BR-DE-11 apply in the same way. The usual cause is an address stored as a single text field.

Fix: split the address into street, post code and city. In UBL the elements are cbc:PostalZone and cbc:CityName under cac:PostalAddress; in CII they are ram:PostcodeCode and ram:CityName under ram:PostalTradeAddress.

4. BR-DE-21: wrong specification identifier in BT-24

BR-DE-21 checks that BT-24 matches the XRechnung identifier. For version 3.0 it is urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0. Common causes are older identifiers containing xoev-de from XRechnung 2.x, typos, or the plain EN 16931 identifier urn:cen.eu:en16931:2017.

The rule itself is only a warning. However, the KoSIT validator picks its validation scenario from BT-24. If no scenario matches, the result is 'reject'. With the plain EN 16931 identifier, only the European rules run, and the recipient will not treat the file as an XRechnung. Fix cbc:CustomizationID (UBL) or rsm:ExchangedDocumentContext/ram:GuidelineSpecifiedDocumentContextParameter/ram:ID (CII). KoSIT published a pre-release of XRechnung 4.0 in September 2026, with the final version expected in spring 2027. Switch only once your recipients accept it.

5. BR-DE-1 and BR-DE-23: payment details missing or inconsistent

BR-DE-1 requires the PAYMENT INSTRUCTIONS group (BG-16), so at least a payment means code in BT-81. BR-DE-23 applies to credit transfers: if BT-81 is 30 or 58, the CREDIT TRANSFER group (BG-17) with the IBAN in BT-84 must follow, and the card (BG-18) and direct debit (BG-19) groups must not appear. For SEPA direct debit (code 59), BR-DE-25, BR-DE-30 and BR-DE-31 require the creditor ID (BT-90) and the payer's IBAN (BT-91).

Fix: in UBL, fill cac:PaymentMeans/cbc:PaymentMeansCode and cac:PaymentMeans/cac:PayeeFinancialAccount/cbc:ID; in CII, ram:SpecifiedTradeSettlementPaymentMeans/ram:TypeCode and ram:PayeePartyCreditorFinancialAccount/ram:IBANID. Write the IBAN without spaces, or the warning BR-DE-19 flags it as invalid. If an amount is due, also give a due date (BT-9) or payment terms (BT-20). Older validator configurations, such as the KoSIT configuration of October 2024, require this as rule BR-CO-25; the configuration of 31 August 2026 (CEN Schematron 1.3.16) no longer contains that rule.

6. BR-DE-18: early-payment discount badly formatted

BR-DE-18 is a fatal error. An early-payment discount (Skonto) must appear in the payment terms (BT-20) in a machine-readable line: #SKONTO#TAGE=14#PROZENT=2.00#. The percentage needs a decimal point and exactly two decimals, everything is upper case with no spaces, and each discount line ends with a line break. If the discount applies to part of the amount only, add #BASISBETRAG=…# with two decimals.

Fix: put free text such as '2% discount if paid within 14 days' on its own line without a leading #. Only lines starting with # are checked against the pattern. In UBL, BT-20 lives in cac:PaymentTerms/cbc:Note; in CII, in ram:SpecifiedTradePaymentTerms/ram:Description.

7. BR-CO-10 and the totals chain: amounts do not add up

BR-CO-10 requires BT-106 to equal the exact sum of all line net amounts (BT-131). More rules build on it: BR-CO-13 checks the net total BT-109 (lines minus allowances BT-107 plus charges BT-108), BR-CO-15 the gross total BT-112 (BT-109 plus VAT BT-110) and BR-CO-16 the amount due BT-115 (BT-112 minus prepaid BT-113 plus rounding BT-114).

Rounding is the usual cause. Example: 7 units at €1.235 make €8.645. The line must show €8.65 in BT-131, because amounts allow at most two decimals. BT-106 is then the sum of the already rounded lines. Summing unrounded values and rounding only the total creates one-cent gaps.

8. BR-S-08 and BR-CO-17: VAT breakdown wrong

Each VAT rate needs its own breakdown (BG-23). BR-S-08 requires the taxable amount BT-116 per rate to equal the matching lines plus charges minus allowances. BR-CO-17 requires the tax amount BT-117 to equal BT-116 × BT-119 / 100, rounded to two decimals. Example: lines at 19% totalling €99.99 give €18.9981, so €19.00 VAT.

For category E (exempt, for example a small business under § 19 UStG, the Kleinunternehmer scheme), BR-E-10 requires an exemption reason in BT-120 or BT-121. For reverse charge (category AE), BR-AE-10 requires the reason 'Reverse charge'. BR-DE-14 always requires the rate BT-119, so 0 for E and AE. In UBL the values sit in cac:TaxTotal/cac:TaxSubtotal; in CII in ram:ApplicableHeaderTradeSettlement/ram:ApplicableTradeTax.

9. BR-CO-9, BR-CO-26, BR-S-02: tax number missing or in the wrong field

A frequent mistake is putting the German tax number (Steuernummer) into the VAT ID field BT-31. BR-CO-9 then fires, because BT-31 must start with a country code such as 'DE'. BR-CO-26 requires a seller identifier (BT-29, BT-30 or BT-31), and BR-S-02 requires BT-31, BT-32 or BT-63 for standard-rated lines. The OZG-RE FAQ names BR-CO-9 and BR-CO-26 as signs of a wrongly entered tax number.

Fix: in UBL the VAT ID goes into cac:PartyTaxScheme/cbc:CompanyID with tax scheme VAT, and the tax number into a second cac:PartyTaxScheme with tax scheme FC. In CII it is ram:SpecifiedTaxRegistration/ram:ID with schemeID="VA" or schemeID="FC". This is also a mandatory VAT detail under § 14(4) UStG.

10. Schema errors: the file is technically broken

If the XML schema check fails, the business rules often never run. Our error reference groups these cases as SCHEMA-001 (not well-formed), SCHEMA-002 (wrong namespace or root element) and SCHEMA-003 (mandatory element missing or out of place). The KoSIT validator reports them as schema messages such as 'cvc-complex-type.2.4.a: Invalid content was found starting with element …'.

Typical causes: elements in the wrong order (UBL prescribes it), dates in the wrong format (UBL 2026-09-28, CII 20260928 with format="102"), a decimal comma instead of a point, an unescaped & or a wrong namespace. To inspect the file, open it in our XML Viewer. Both syntaxes are laid out in our guide to the XRechnung XML structure.

Which warnings should you still fix?

Warnings do not block validation, but they can trigger questions from the recipient:

• BR-DE-17: BT-3 should be one of 326 (partial invoice), 380 (commercial invoice), 384 (corrected invoice), 389 (self-billed invoice), 381 (credit note), 875, 876 and 877 (partial, partial final and final construction invoice).
• BR-DE-26: with code 384, the original invoice should be referenced in BG-3 (UBL cac:BillingReference/cac:InvoiceDocumentReference/cbc:ID).
• BR-DE-19 and BR-DE-20: invalid IBAN for SEPA credit transfer (58) or SEPA direct debit (59).
• BR-DE-27 and BR-DE-28: phone number or email address looks malformed.

BR-DE-22, by contrast, is fatal: embedded attachments need unique file names. See our guide to XRechnung attachments.

Format, business-rule and content errors: what the Finance Ministry says

The Finance Ministry letter of 15 October 2025 (opens in a new tab) (BMF-Schreiben) separates three error classes (paras. 6a, 6b and 35a):

A content error can exist even when validation passes, for example 7% charged instead of 19%. Validation does not replace the recipient's own check. A business may, however, rely on the technical result of a suitable validation tool. Keep the validation report as evidence; our guide to e-invoice archiving shows how. The VAT details themselves can be checked with our German invoice requirements checker.

XRechnung rejected: what now?

Federal invoices run through the OZG-RE platform. According to the federal e-invoicing FAQ (opens in a new tab), either the platform rejects an invoice for formal or arithmetic errors, or the recipient rejects it for content errors. Proceed like this:

1. Check the status: the OZG-RE uses New, Duplicate detected, Provided, Delivered, Rejected and Deleted (Neu, Duplikat erkannt, Bereitgestellt, Zugestellt, Zurückgewiesen, Gelöscht).
2. Open the details: for invoices sent by email or Peppol, the magnifying-glass icon in the invoice list opens the detailed results of the formal check. With the web form or upload channel, you can validate directly on the platform.
3. Look up the rule ID and fix the cause in your invoicing system, not by hand in the XML.
4. Validate again, for example with our e-invoice validator, which applies the official KoSIT rules and explains each message.
5. Resubmit. If the recipient rejected the invoice, read their comment and ask the invoicing office whether they expect a corrected invoice.

In B2B there is no central platform. Whether a faulty file is rejected depends on the recipient's software.

How to prevent XRechnung errors for good

After software updates, and before moving to XRechnung 4.0, compare your output with a known valid file; our xrechnung example works as a reference. Without invoicing software, you can create an e-invoice online; the form asks for the fields behind errors 1 to 6. Our step-by-step XRechnung guide covers the process in detail. More articles are in the validation and errors category.