When a German public-sector portal rejects your XRechnung, everything about the message is German except the part that matters: the rule code. BR-DE-15, BR-DE-2, BR-DE-1 and their siblings are stable, documented identifiers, and each one points at a specific field. You do not need to translate the prose around them. Find the code, look it up below, fix that one field, send the same invoice again.
Three words worth knowing anyway
| German | Meaning | What it implies |
|---|---|---|
| abgelehnt / zurückgewiesen | rejected | The file was never accepted; it does not exist for the buyer |
| Fehler | error | Blocks the invoice; must be fixed |
| Warnung | warning | Does not block by itself, but strict receivers may still refuse |
The first row carries the most important consequence: a rejected invoice was never received, so there is nothing to cancel and no credit note to write. You correct the file and resubmit it, normally under the same invoice number.
The codes that block your invoice
These rules are classified as errors: violate one and the file is refused.
| Code | What is missing | What to do |
|---|---|---|
| BR-DE-15 | Buyer reference (BT-10): the buyer's Leitweg-ID, a routing code like 991-33333TEST-33 | Ask your customer for their Leitweg-ID and put it in the buyer reference field, nowhere else |
| BR-DE-2, 5, 6, 7 | Seller contact: a name, a phone number and an email address as data fields | Fill all three; a department name and a shared mailbox are fine |
| BR-DE-1 | Payment instructions: at least the payment means code, with your IBAN for a transfer | Set the payment means (58 for SEPA transfer) and add the IBAN |
| BR-DE-16 | Your VAT identifier or German tax number as a data field | Enter your VAT ID (for foreign suppliers usually your home VAT number) |
| BR-DE-18 | Cash-discount terms not in the prescribed machine pattern | If you offer none, remove the coded line; the pattern is a strict German notation |
| BR-DE-23, 24 | Payment data inconsistent with the payment means code | With a transfer code, include the account and drop card or direct-debit blocks |
Rules starting BR-CO come from the European standard itself and usually mean the totals or the VAT breakdown do not add up; recalculate rather than round by hand.
The codes that only warn
| Code | What it flags | Why you should still care |
|---|---|---|
| BR-DE-21 | The specification identifier (BT-24) is not the XRechnung one | Receivers pick their rule set by this value; a wrong one can sink the file anyway |
| BR-DE-17 | An invoice type code outside the accepted German list | Many portals refuse such files in practice; 380 is the safe default |
| BR-DE-19 | The IBAN looks invalid | The check may pass, your payment will not arrive |
| BR-DE-26 | A correction invoice (type 384) without a reference to the original | The buyer cannot match it |
| BR-DE-27, 28 | Phone or email look like placeholders | Usually a "-" typed into a required field |
The fastest repair, in English
The slow way is rebuilding the invoice in your own billing tool and hoping the export changes. The fast way works on the rejected file itself:
- Open the rejected XML in the XRechnung editor. It renders the file as a form, in English, so you can see and change the one field the code points at.
- Validate before resubmitting with the XRechnung validator. It runs the same official German rule set the portal runs and reports every finding in plain language, so the next rejection email never gets written.
- Resubmit through the same channel with the same invoice number. Only fix the root cause in your billing software afterwards, calmly, so the next invoice does not repeat it.
If you are unsure what the file actually contains, the XRechnung viewer shows the data the way a German clerk will see it.
When the file is fine and it still fails
- Wrong channel: the federal ZRE portal was switched off in September 2025; federal invoices go through the OZG-RE platform or the Peppol network now.
- Formally valid but wrong Leitweg-ID: the invoice is accepted and routes to the wrong office. Confirm the ID with the person who ordered.
- Attachments: portals restrict file types and sizes for embedded documents.
- Buyer-specific demands: an order number the standard does not require, but the contract does. That sits in your contract documents, not in the rule set.
What to do now
- Pull the code out of the rejection report and match it against the tables above.
- Repair the rejected file directly instead of rebuilding it.
- Validate, then resubmit under the same number.
- Fix your billing software's template afterwards, so the same code does not come back next month.
Further reading
What Germany actually demands from foreign suppliers, and when you can decline the whole exercise, is covered in Your German customer wants an e-invoice. The deadlines and formats from the German side are mapped in the e-invoicing guide for English-speaking businesses. And if you are on the receiving end instead, start with An e-invoice arrived.
Legal position as at September 2026, last reviewed on 25 September 2026. Based on the KoSIT validation rules for XRechnung 3.0 with their classification as errors or warnings, the European standard EN 16931 and the published guidance of the German invoice portals. Individual buyers may impose additional requirements.
Frequently asked questions
Do I have to cancel a rejected invoice or issue a credit note?
No. A rejected invoice was never accepted and is not booked anywhere. You correct the file and submit it again, normally under the same invoice number. Credit notes only come into play once an invoice was accepted.
Can I resubmit with the same invoice number?
Yes, that is the normal way. The rejected submission does not exist for the buyer, so the number is still free.
Can I ignore warnings?
Not safely. A warning alone does not block the file, but many receiving systems check more strictly than the formal rule set, and a wrong specification identifier or an implausible type code sinks invoices in practice.
My billing software says the XML is valid. Why was it still rejected?
Because several rule layers apply. The XML schema checks structure only; above it sit the European business rules and the German BR-DE rules. A file can be schema-valid and still miss a German mandatory field like the buyer reference.
Where do I find my customer's Leitweg-ID?
From the customer: it is usually in the order, the contract or the tender documents. There is no public directory. Ask before you invoice, because without it the file cannot pass.