Common XRechnung Validation Errors and How to Fix Them

Your e-invoice was rejected by a German authority's portal or by your customer's system, or a validator shows a list of red error codes. This is common, and it is usually easy to fix. This guide explains how XRechnung validation works, how to read an error report, and what the most frequent errors mean in plain English – with the fix for each one.

How XRechnung validation works

A validator checks your invoice in several layers. An error in any layer can lead to a rejection:

1. XML schema: is the file well-formed XML in the correct syntax (UBL or CII), with the right elements in the right order and the right data types?
2. EN 16931 business rules: the European standard defines rules such as mandatory fields, calculations and VAT logic. Their IDs start with BR- (for example BR-CO-15 or BR-S-08).
3. Code lists: currencies, countries, units, VAT categories and document types must use official codes. These rules start with BR-CL-.
4. XRechnung rules: XRechnung is the German specification (CIUS) of EN 16931. It adds national rules with IDs starting with BR-DE-, for example a mandatory seller contact and buyer reference.
5. ZUGFeRD profile (for PDF invoices): a ZUGFeRD or Factur-X file must be a PDF/A-3 with the XML embedded, and the profile must be sufficient. The MINIMUM and BASIC WL profiles do not count as e-invoices in Germany.

In Germany, the official reference tool is the validator of KoSIT (the German Coordination Office for IT Standards), which applies these rule sets. Many portals and software products use it in the background.

How to read a validation report

Each finding in a report usually has three parts:

• Rule ID: for example [BR-DE-15]. The prefix tells you the source: BR-DE for XRechnung rules, BR-CL for code lists, other BR- IDs for EN 16931.
• Severity: “fatal” or “error” means the invoice is not compliant and will normally be rejected. “Warning” means the invoice is technically valid, but a value should be checked.
• Location: an XPath expression shows where in the XML the problem is. The message also names the business term, for example “Buyer reference (BT-10)”.

Many messages from the XRechnung rule set are in German. “muss übermittelt werden” means “must be provided”; “soll” means “should”. The BT and BG codes are the field numbers of EN 16931. Our annotated German e-invoice example shows where each field sits in a real XML file.

The most common XRechnung errors and how to fix them

BR-DE-15: Buyer reference (BT-10) is missing

XRechnung requires a buyer reference on every invoice. For German public authorities, this field must contain the Leitweg-ID (the routing ID the authority gives you). For business customers, use the reference your customer asked for, such as a purchase order or cost centre number. Fix: ask your customer for the correct value and enter it in the buyer reference field.

BR-DE-2, BR-DE-5, BR-DE-6, BR-DE-7: Seller contact is missing

XRechnung requires a seller contact group (BG-6) with a contact point or name (BT-41), a telephone number (BT-42) and an email address (BT-43). Fix: add a contact person, phone number and email address to your company settings. Related warnings BR-DE-27 and BR-DE-28 appear when the phone number has fewer than three digits or the email address does not look valid.

BR-DE-3, BR-DE-4, BR-DE-9: Address details are incomplete

The seller's city (BT-37) and post code (BT-38) and the buyer's post code (BT-53) are mandatory in XRechnung. Fix: complete the address data for your company and the customer.

BR-DE-1, BR-DE-23: Payment instructions are missing or inconsistent

BR-DE-1 requires payment instructions (BG-16). BR-DE-23 applies when the payment means code (BT-81) is a credit transfer (30 or 58): then the credit transfer details (BG-17), such as the IBAN, must be provided, and card or direct debit details must not. Fix: choose the correct payment method and enter your bank details. Use code 58 for SEPA credit transfer.

BR-DE-16: Seller VAT ID or tax number is missing

If the invoice uses VAT categories such as S (standard rate), the seller VAT identifier (BT-31), the tax registration number (BT-32) or a tax representative must be present. Fix: enter your VAT ID (USt-IdNr.) or German tax number (Steuernummer) in your company settings.

BR-CO-10 and BR-CO-15: Totals do not add up

BR-CO-10 checks that the sum of line net amounts (BT-106) equals the total of all line amounts (BT-131). BR-CO-15 checks that the total with VAT (BT-112) equals the total without VAT (BT-109) plus the total VAT (BT-110). The usual cause is rounding at different steps or a line that was changed by hand without recalculating the totals. Fix: round each amount to two decimals in a consistent way and let your software calculate all totals.

BR-S-08: VAT breakdown does not match the lines

For each standard VAT rate, the taxable amount in the VAT breakdown must equal the sum of the lines with that rate (plus or minus document-level charges and allowances). Fix: check that every line has the correct VAT rate and that there is one breakdown entry per rate, for example 19 % and 7 %.

BR-DE-21: Wrong specification identifier (BT-24)

The specification identifier tells the receiver which standard the invoice follows. If it does not match the XRechnung identifier, you get a warning – and in practice the validator may not apply the XRechnung rules at all, so many portals will not accept the file. Fix: make sure your software writes the identifier for the current XRechnung version. You cannot fix this field in a normal invoice form; it is set by the software.

BR-DE-18: Early payment discount (Skonto) in the wrong format

In XRechnung, an early payment discount (Skonto) in the payment terms must follow a fixed text pattern. If it does not, the rule BR-DE-18 fails. Fix: enter the discount in your software's dedicated discount fields instead of free text in the payment terms.

BR-CL rules: A code is not in the official list

Code list errors appear when a value is entered as free text. Typical examples:

• BR-CL-03/04: currency must be an ISO 4217 code, for example EUR, not “€”.
• BR-CL-14: country must be an ISO 3166-1 code, for example DE or GB, not “Germany”.
• BR-CL-23: unit of measure must come from UN/ECE Recommendation 20/21, for example HUR for hour or C62 for piece, not “hrs” or “pcs”.
• BR-CL-17/18: VAT category must come from UNCL 5305, for example S for standard rate.
• BR-CL-01: document type must come from UNTDID 1001, for example 380 for a commercial invoice.

Schema errors: dates and numbers in the wrong format

Schema errors occur before any business rule is checked. Common causes are dates in a local format such as 17.10.2026 instead of the required format, a comma instead of a dot as decimal separator, or elements in the wrong order. These errors almost always come from the software that created the file. Fix: create the invoice again with software that produces standard-compliant XML.

ZUGFeRD-specific problems

For ZUGFeRD or Factur-X PDFs, check that the file is a PDF/A-3, that the XML is properly embedded, and that the profile is EN 16931 (COMFORT), EXTENDED or XRECHNUNG – not MINIMUM or BASIC WL. If the visible PDF was changed after the XML was created, the two no longer match; the structured data is what counts. More on the formats: XRechnung vs ZUGFeRD explained.

How to fix a rejected invoice in five steps

1. Note the rule ID and the field named in the report.
2. Correct the data in your invoicing software – not by editing the XML by hand.
3. Create the e-invoice file again.
4. Validate it again until no fatal errors remain, and review any warnings.
5. Send the corrected invoice through the same channel, following your customer's or the portal's rules for rejected invoices.

Validate your invoice free of charge with XRechnungs.de

The free XRechnung validator from XRechnungs.de accepts XRechnung XML files and PDF files with embedded XRechnung or ZUGFeRD/Factur-X data. It checks EN 16931 compliance with the KoSIT validator, adds extended business rules, and shows a report with errors, warnings and correction hints. Validation runs on servers in Germany, and files are not stored permanently unless you choose to save them.

A report without errors confirms the technical checks. It does not replace any additional checks your customer or a public portal may apply.

When your software keeps producing the same error

If you correct the data and the error appears again, the problem is probably in the software, not in your invoice. Typical signs are wrong specification identifiers, schema errors or missing fields that the software has no input for. Report the rule ID to your software provider, or switch to a tool that creates and validates XRechnung and ZUGFeRD before sending. With XRechnungs.de you create e-invoices directly in both formats; if you only have PDFs today, read how to convert a PDF invoice to ZUGFeRD or XRechnung.

FAQ: XRechnung validation errors

Why was my XRechnung rejected?

The most common causes are a missing buyer reference or Leitweg-ID (BR-DE-15), missing seller contact details (BR-DE-2), missing payment details (BR-DE-1, BR-DE-23), totals that do not add up (BR-CO-10, BR-CO-15) and codes that are not in the official lists (BR-CL rules).

What does BR-DE-15 mean?

The buyer reference (BT-10) is missing. For German public authorities, enter the Leitweg-ID; for business customers, use the reference they gave you.

What is the difference between an error and a warning?

An error (fatal) means the invoice does not meet the rules and will normally be rejected. A warning does not make the invoice invalid, but you should check the value.

Can I fix the XML file by hand?

It is not recommended. Manual edits easily create new errors, and in a ZUGFeRD file the visible PDF would no longer match the XML. Correct the data in your software and create the file again.

Is the XRechnungs.de validator free?

Yes. You can validate XRechnung and ZUGFeRD files online free of charge.

Does a valid report guarantee that my invoice will be accepted?

No. It confirms the technical checks. Your customer or a public portal may apply additional checks, for example on the Leitweg-ID or order number.

Conclusion

A validation error is rarely a mystery: the report tells you which rule failed and which field is affected. Fix the data at the source, create the file again and validate before you send it. To understand the wider rules, read our guide to Germany's e-invoicing mandate.

Next step: validate your e-invoice now, or try XRechnungs.de free for 14 days – up to 50 documents, no credit card required.