Last updated: May 2026
Understanding XRechnung Test Report & Error Messages
What does a KoSIT test report say?
A KoSIT test report shows whether an XRechnung meets the formal requirements of the standard. It contains the check result (compliant or non-compliant), the assessment (accept or reject), the document type (UBL or CII), the validator version used, and a list of violated rules with codes such as BR-DE-01 or BR-CO-15. Only by reading these codes does it become clear where a BT field is missing or incorrectly filled.
→ Check XRechnung online for free now
Table of Contents
- Understanding XRechnung Test Report & Error Messages
- Anatomy of a KoSIT test report
- The most common BR-DE errors at a glance
- UBL or CII – why the syntax changes the error message
- BT number glossary – the most important fields
- “Conformist, but rejected” – what’s behind it?
- What to do after an error message
- XRechnung Versions – An Overview
- FAQ – XRechnung Test Report
- Validate yourself now
Anatomy of a KoSIT test report
The official KoSIT validator outputs a structured report in HTML or XML format. It is divided into five areas:
- Document information: File name, check time, recognized document type (UBL Invoice, UBL CreditNote or UN/CEFACT CII).
- Conformity result: “compliant” or “non-compliant” to the XRechnung standard in the applied version.
- Rating: The report recommends either acceptance or rejection. A compliant invoice can still be rejected if technical rules (BR-CO-…) are violated.
- Rule violations: List with code, severity (error, warning) and affected XPath. Here you will find the reference to the BT number.
- Validator version: Which configuration of the KoSIT was used, such as xrechnung-3.0.2-2024-09-30.
The most common BR-DE errors at a glance
About 80 percent of all rejections can be traced back to a manageable list of rules. The following table explains the most common codes with cause and solution.
| Code | Importance | Typical cause | solution |
|---|---|---|---|
| BR-EN-01 | Mandatory information: Leitweg ID is missing | BT-10 (Buyer reference) not filled | Enter the recipient’s routing ID in the field cbc:BuyerReference . |
| BR-EN-02 | Seller’s contact information incomplete | BG-6 without name, phone or email | Fill in at least BT-41, BT-42 and BT-43. |
| BR-EN-03 | Seller’s city is missing | BT-37 empty | City in the seller’s address. |
| BR-EN-04 | Seller’s zip code is missing | BT-38 empty | Set the zip code in the seller’s address. |
| BR-EN-05 | Seller’s country code is missing | BT-40 blank or no ISO 3166-1 | Enter a two-digit ISO code (e.g. DE). |
| BR-EN-09 | Buyer’s city is missing | BT-52 empty | City in the buyer’s address. |
| BR-EN-15 | Buyer reference required | BT-10 is missing or not in the expected format | Enter the routing ID or order number. |
| BR-EN-17 | Invalid code for invoice type | BT-3 not 380, 381, 384, 389 or 875-881 | Choose the correct UN/CEFACT code. |
| BR-EN-21 | Name of the invoice item is missing | BT-153 empty | Item name per item. |
| BR-EN-23 | Payment Terms Required | BT-20 or BG-16 are missing | Means of payment code (BT-81) and set maturity. |
| BR-EN-26 | IBAN required for SEPA transfer | BT-84 empty despite Payment Means 58 | Enter IBAN in the format without spaces. |
| BR-CO-10 | Sum of Item Amounts Incorrect | BT-106 differs from BT-131 sum | Mathematically consistent calculation of net item amounts. |
| BR-CO-13 | Subtotal inconsistent | BT-109 ≠ BT-106 − BT-107 + BT-108 | Correctly calculate discounts and surcharges at document level. |
| BR-CO-15 | Gross amount is not correct | BT-112 ≠ BT-109 + BT-110 | Check the tax amount and compensate for rounding differences. |
UBL or CII – why the syntax changes the error message
XRechnung allows two syntaxes: UBL 2.1 (common in Germany) and UN/CEFACT Cross Industry Invoice (CII). The test report refers to the affected element via XPath. In UBL, the recipient country is called something , /Invoice/cac:AccountingCustomerParty/cac:Party/cac:PostalAddress/cac:Country/cbc:IdentificationCodein CII /rsm:CrossIndustryInvoice/ram:ApplicableHeaderTradeAgreement/ram:BuyerTradeParty/ram:PostalTradeAddress/ram:CountryID. In terms of content, this is the same BT number (BT-55), only the path differs. If you look up the BT number in the glossary, you will find the error regardless of the syntax.
BT number glossary – the most important fields
| BT number | Importance |
|---|---|
| BT-1 | Invoice number |
| BT-2 | Invoice issue date |
| BT-3 | Invoice type code (e.g. 380 = commercial invoice) |
| BT-5 | Currency of the invoice |
| BT-9 | Due date |
| BT-10 | Buyer Reference / Route ID |
| BT-23 | Business process type (for example, urn:fdc:peppol.eu:2017:poacc:billing:01:1.0) |
| BT-24 | Specification Identifier (XRechnung CIUS) |
| BT-27 | Name of the seller |
| BT-44 | Buyer’s Name |
| BT-48 | Tax number of the buyer (VAT number) |
| BT-81 | Payment method code (e.g. 58 = SEPA Credit Transfer) |
| BT-84 | IBAN for SEPA transfer |
| BT-106 | Sum of item amounts excluding tax |
| BT-112 | Gross amount (total amount including tax) |
| BT-115 | Amount to be paid |
“Conformist, but rejected” – what’s behind it?
An XRechnung can be technically compliant and still trigger the recommendation “Reject”. The KoSIT validator checks two levels: compliance with the scheme and the business rules (BR-CO-…). If an invoice violates a business rule, for example because sums do not match or a mandatory information such as the IBAN is missing for transfer payments, it is syntactically correct, but technically incomplete. In this case, the recipient – especially public contracting authorities – may formally reject the invoice.
What to do after an error message
- Note the error code and look for the XPath or BT number in the report.
- Identify BT field in the generating system (ERP, invoicing, SAP).
- Recheck the corrected file – ideally with the same validator version.
- Document frequency: If codes such as BR-DE-01 appear systematically, there is a configuration problem in the source system.
XRechnung Versions – An Overview
Which version your validator uses can be found in the test report. A complete version table with validity periods can be found on the XRechnung overview page. Important for practice: Version 3.0.2 will apply from January 1, 2025; Version 4.0 is expected at the end of 2026.
FAQ – XRechnung Test Report
Who provides the test module for XRechnung?
The Coordination Office for IT Standards (KoSIT) develops and publishes the official validator including configuration files. Source: xoev.de.
What does “non-compliant” mean in the test report?
The file violates one or more schema rules or business rules. The invoice may be rejected by the recipient until the error is corrected.
What is the difference between UBL and CII in XRechnung?
UBL and CII are two permissible syntaxes with identical business data models. The BT numbers remain the same, the XML element names and XPaths differ.
Is a compliant test report sufficient for shipment approval?
No. Conformity means only schema fidelity. In practice, there are business rules (BR-CO-…) and, if necessary, CIUS-specific rules such as BR-DE-… .
Validate yourself now
Would you like to check an XRechnung immediately? Our e-invoice validator uses the current KoSIT verification module, runs browser-based and delivers the report in a few seconds – without registration. For the generation and sending of XRechnung directly from SAP, we recommend our SAP E-Invoice solution.
→ To the free e-invoice validator
