1. Home
2. Guides
3. Validate an XRechnung

Validate an XRechnung and fix the errors that come up most

Upload the XML to the free validator or POST it to the API, and you get every finding with its rule ID and where it is in the file. This page explains how to read the report and how to fix the errors people hit most.

Updated 19 October 2026

How the check works

The validator reads the specification identifier (BT-24) to decide which rules apply, then runs the official KoSIT validator with the official XRechnung configuration, in three steps:

1. XML schema (UBL 2.1 or CII): structure, element order, data types.
2. EN 16931 rules (BR-*, BR-CO-*, BR-CL-* …), the European core rules.
3. XRechnung rules (BR-DE-*), the German additions.

Each finding has a severity. Errors (fatal) make the invoice invalid. Warnings don't, but receivers may still complain. Information findings are hints, for example BR-DE-TMP-32.

curl https://validate.invoir.dev/api/v1/validate \
  -H "Authorization: Bearer inv_YOUR_KEY" \
  -F [email protected]

Nothing is stored: files are processed in memory and discarded. The API docs describe the JSON report.

Schema errors (no rule ID)

If the XML doesn't match the schema, you see parser messages with a line number instead of rule IDs. The usual causes:

• Element order. UBL elements must appear in the schema's sequence, for example cac:TaxTotal, then cac:LegalMonetaryTotal, then the cac:InvoiceLine elements. Generating XML from a dictionary often breaks this.
• Dates. UBL wants 2026-10-19; CII wants <udt:DateTimeString format="102">20261019</udt:DateTimeString>.
• Numbers. A dot as decimal separator and no thousands separator. (Amounts with more than two decimals pass the schema but fail the BR-DEC-* rules.)
• Namespaces. A wrong or missing namespace makes every element "unexpected".

XRechnung rules (BR-DE)

BR-DE-15 The element "Buyer reference" (BT-10) must be provided

The most common one. For public authorities, BT-10 is the Leitweg-ID they gave you. For businesses, use the reference your customer asked for (a PO number, a cost centre). UBL: cbc:BuyerReference; CII: ram:BuyerReference in the header trade agreement.

BR-DE-2, BR-DE-5, BR-DE-6, BR-DE-7 Seller contact, contact point, telephone, email

XRechnung needs a seller contact group (BG-6) with a name or department (BT-41), a phone number (BT-42) and an email address (BT-43). Warnings BR-DE-27 and BR-DE-28 follow if the phone has fewer than three digits or the email looks wrong.

BR-DE-1 An invoice must contain "Payment instructions" (BG-16)

State the payment means. With code 30 or 58 (credit transfer, SEPA credit transfer), BR-DE-23-a requires the credit transfer group (BG-17) and BR-61 the account (BT-84, usually the IBAN). BR-DE-19 warns if a SEPA IBAN looks wrong.

BR-DE-3, BR-DE-4, BR-DE-8, BR-DE-9 City and post code

Seller and buyer addresses need both.

BR-DE-16 Seller VAT identifier or tax number

When a VAT category S, Z, E, AE, K, G, L or M is used, the seller VAT ID (BT-31), the tax number (BT-32) or a tax representative (BG-11) must be there.

BR-DE-14 "VAT category rate" (BT-119) must be provided

Every VAT breakdown entry carries its rate, also 0 for zero-rated or exempt categories.

BR-DE-21 (warning) Specification identifier

BT-24 should be the XRechnung identifier, for version 3.0 urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0.

BR-DE-TMP-32 (information) Delivery date or period

Give the actual delivery date (BT-72), an invoicing period (BG-14), or a period on every line (BG-26).

EN 16931 rules that fail in XRechnung too

BR-CO-15, BR-CO-13, BR-CO-10, BR-CO-16 Totals

The totals must add up from the rounded values in the file. Compute sums from what you write, not from internal floats.

BR-CO-17, BR-S-08, BR-S-09 VAT breakdown

Compute VAT per category and rate on the taxable amount and round once, to two decimals. Per-line rounding produces cent differences.

BR-CL-23 Unit code

UN/ECE Rec 20/21 codes: C62 for pieces, HUR for hours. "Stk" fails.

All EN 16931 rule families are explained on the EN 16931 page.

What a passing report does not tell you

• Whether the Leitweg-ID exists and belongs to the authority you mean.
• Whether the receiving portal adds its own checks (some do).
• Whether the invoice is commercially right: prices, quantities, the customer.

Validation isn't a legal precondition in Germany, but the Federal Ministry of Finance recommends validating every e-invoice when it is created and sent (BMF FAQ, question 7). Put the API call into your test suite and your issuing pipeline, and no invoice that fails the official rules leaves your system.

Sources

• KoSIT: XRechnung validator configuration (rule IDs and texts quoted above), XRechnung.
• CEN/TC 434: EN 16931 validation artefacts.
• Bundesministerium der Finanzen: FAQ E-Rechnung, question 7.