Common XRechnung Rejection Reasons at Authorities — and How to Fix Them

An XRechnung that a public authority rejects is not just an inconvenience — it delays your payment. The frustrating part is that most rejections come from a small, predictable set of causes, and every one of them is catchable before you send. This article lists the frequent rejection reasons against the current XRechnung 3.0.2 standard and gives the concrete fix for each.

> Short answer: The frequent rejections are: missing/invalid Leitweg-ID in BT-10 (BR-DE-15); failed KoSIT Schematron BR-DE-* rules (e.g. BR-DE-1 payment means/IBAN, seller contact BT-41/42/43); wrong version string in BT-24 (BR-DE-21); VAT category/rate/amount inconsistencies, missing seller VAT ID (BR-CO-9), rounding (BR-CO-10); and attachment/file-size limits. Fix them all by validating with the free KoSIT validator before sending.

The standard you must hit: XRechnung 3.0.2

The current standard is XRechnung 3.0.2, in effect since 1 February 2025. Targeting an older version is itself a source of rejection, so start by confirming your tooling produces 3.0.2.

1. Missing or invalid Leitweg-ID (BT-10, BR-DE-15)

The single most common rejection. For B2G, the buyer reference BT-10 must carry the recipient's Leitweg-ID — it is mandatory and enforced by BR-DE-15. The format looks like 05111-01001-54 and includes a check digit, so a transposed digit fails.

Fix: Get the correct Leitweg-ID from the authority (it is on the order, contract, or grant notice) and place it in BT-10 exactly. Do not invent or reformat it.

2. Failed KoSIT Schematron rules (BR-DE-*)

XRechnung layers German business rules (BR-DE-*) on top of EN 16931, checked by the KoSIT Schematron validator. Frequent offenders:

• BR-DE-1 — payment means / IBAN requirements not met
• Seller contact — missing BT-41 / BT-42 / BT-43 (contact name, phone, email)

Fix: Run the file through the KoSIT validator; it names the exact failing rule. Populate the required seller contact and payment fields.

3. Wrong syntax or version string (BT-24, BR-DE-21)

The specification identifier in BT-24 must be exactly:

urn:cen.eu:en16931:2017#compliant#urn:xrechnung:3.0

This is enforced by BR-DE-21. A wrong, outdated, or slightly mistyped string is rejected even if everything else is perfect.

Fix: Ensure BT-24 carries the exact string above. This is usually a tooling setting, not a data-entry field.

4. VAT inconsistencies (UNTDID 5305, BR-CO-9, BR-CO-10)

The tax layer is a rich source of rejections:

• Category code must be a valid UNTDID 5305 value: S (standard), Z (zero-rated), E (exempt), AE (reverse charge), K (intra-EU), G (export), O (out of scope)
• Category, rate, and amount must be consistent — a line marked S at 0% is contradictory
• Missing seller VAT ID fails BR-CO-9
• Rounding errors fail BR-CO-10 — the tax breakdown must reconcile with the line totals

Fix: Use the right category per line, ensure the seller VAT ID is present, and let a reliable tool compute the tax breakdown so rounding reconciles.

5. Attachment and file-size limits

Even a valid XRechnung can be rejected on attachment or file-size limits — an embedded attachment that is too large, or too many attachments for the receiving platform.

Fix: Keep attachments minimal and within the platform's stated limits; move bulky supporting documents to a separate channel if allowed.

Rejection reasons at a glance

The one habit that prevents almost all of these

Every rejection above is detectable before an authority ever sees the file. The fix that covers all of them is the same: validate with the free KoSIT validator before sending. If the validator passes, the platform almost certainly will too. If it fails, it tells you the exact rule to fix — turning a payment-delaying rejection into a two-minute correction at your desk.

For context on how this fits the wider submission process, see sending XRechnung to government agencies and, for credit notes, the type-code and reference rules.

Validate before you send

You never have to learn what a rejection notice looks like if the file passes validation first. Make validation the last step before every submission.

TaxLayer produces KoSIT-validated XRechnung 3.0 files — correct BT-24 version string, Leitweg-ID in BT-10, consistent VAT breakdown — so errors surface at your desk, not at the authority. The first two conversions each month are free — no credit card required.