Why is the invoice rejected when the XML is valid?

Because valid XML is only the first of three checking stages. Syntax and schema check the shape, business rules check the content. An invoice with no seller contact is formally faultless and still not conformant.

Where do I look up what a rule ID means?

In the message itself. Every Schematron rule carries plain text naming the affected field in BT or BG notation — for instance 'The group SELLER CONTACT (BG-6) shall be provided'. That statement is more precise than any translation of it.

Is a warning also an error?

No. A rule flagged warning does not cause rejection; only fatal ones do. Which rule carries which severity is set by the rule set — and the same matter can weigh more heavily in another rule set.

My totals are right, yet BR-CO-10 reports a failure.

Almost always a rounding problem. The rule sums the line amounts and compares against the stated net amount. Rounding each line to two decimals and summing afterwards gives a different result from summing first and rounding after.

Can I check before sending?

Yes, and that is the real advice. A check before sending costs seconds; a rejection costs a payment run. You can check a file right here on this page, without an account.

XRechnung rejected — now what?

Reading the message properly

A usable message names three things, and all three are useful:

text

1[BR-DE-2] fatal
2The group "SELLER CONTACT" (BG-6) shall be provided.

The rule ID (BR-DE-2) says which rule set the violation comes from. Prefixes: BR- European standard · BR-CO- its arithmetic rules · BR-DE- and DE-R- German add-ons · PEPPOL- Peppol rules.
The severity (fatal) says whether the invoice is rejected for it.
The field in BT/BG notation (BG-6) says where to look.

🔴 The biggest time sink is the third point: the message speaks in BT numbers, your system speaks in its own field names. Searching an ERP for BT-10 finds nothing; searching for "routing" finds it at once.

The rules documents actually fail on

BR-DE-2 — seller contact missing

By some distance the most common cause. The German CIUS requires a contact group at the seller: a name and at least a phone number or an email address. Many systems keep those details in the invoice document's footer rather than as a master data field — and then they are absent from the XML.

json

1{
2  "seller": {
3    "name": "Muster GmbH",
4    "email": "info@muster.de",
5    "phone": "+49 30 12345678"
6  }
7}

DE-R-001 — payment instructions missing

Group BG-16 is mandatory. Naming the payment term in running text is not enough; a structured payment means is required — in practice an IBAN and a transfer code.

BR-CO-10 — line totals do not give the net amount

Arithmetically almost always a rounding question. The rule sums the net amounts of the lines and compares them with the stated total net.

🔵 The order decides: round per line to two decimals and sum afterwards. Summing the unrounded values and rounding only the result lands a cent off regularly on invoices with many lines — and a cent is a fatal.

BR-11 — country code missing in the buyer address

A rule of the European standard. It bites surprisingly often on domestic customers, because the country code stays empty in the master record as long as nobody exports.

Discount in the wrong format

A discount is not free text in an XRechnung but a prescribed string in the payment terms field. A sentence like "2 % discount if paid within 10 days" is unambiguous to a person and worthless to a checker — the detail must be encoded, otherwise it is either rejected or ignored.

Leitweg-ID missing or in the wrong field

For invoices to public authorities BT-10 is mandatory. The typical fault is not the missing ID but the ID in the wrong place: in the payment reference, in the order number, or in a free-text field.

What to do when an invoice comes back

1. Check the severity first. If the response contains only warning, the invoice was not rejected for that. Then the cause is elsewhere — often at the recipient, not in the document.

2. Look up the rule ID rather than interpreting the message. A rule's plain text is deliberately terse. The rule itself names the exact expression that was checked, and therefore the place in the document.

3. Check the original, not the generated PDF. With ZUGFeRD the embedded XML decides, not the visible document. The two can diverge, and the check sees only one of them.

4. Re-check after fixing. Rule violations rarely travel alone. A missing contact block often pulls a second message behind it that only becomes visible once the first is resolved.

The most effective step comes earlier

All the faults above share one property: they are detectable before sending. None of them requires knowledge about the recipient, none depends on their system — they are rules that operate on the document itself.

A check inside the generation process costs one call. A rejection costs a payment run, plus the time in which nobody knows why the money is not arriving.