XRechnung Validation Errors: Common Messages and How to Fix Them

How to read a validation message

Every message has a rule ID, a severity and a text. The ID tells you which rule set raised it — and with that, whether the problem lies in the European standard, in the German specification or in the arithmetic.

Severity is what matters most. An error (or fatal) makes the invoice invalid, and it will be rejected. A warning points at missing or implausible data but does not block acceptance. Fix every error first, then decide whether the warnings matter to your recipient.

• BR-… — core EN 16931 rules (mandatory fields)
• BR-CO-… — calculation and condition rules (totals, dependencies)
• BR-S-…, BR-E-…, BR-AE-… — rules per VAT category
• BR-DE-… — additional rules of the German XRechnung
• PEPPOL-EN16931-R… — rules taken over from Peppol, mandatory since XRechnung 3.0

“Buyer electronic address MUST be provided” (PEPPOL-EN16931-R010)

Since XRechnung 3.0 this is the most common message of all. It means the buyer's electronic address (BT-49) is missing. Its counterpart for the seller is PEPPOL-EN16931-R020, “Seller electronic address MUST be provided” (BT-34). Both fields used to be optional, so many older templates and exports leave them out.

In UBL the address is the party's cbc:EndpointID element, in CII the ram:URIUniversalCommunication element. The schemeID attribute states the kind of address: EM for an e-mail address, 0204 for a Leitweg-ID, 9930 for a German VAT ID on the Peppol network.

Fix: enter the Leitweg-ID (for public authorities) or an invoice-intake e-mail address for the buyer, and your own invoicing e-mail for yourself. In the Toolula E-Invoicing Studio the Leitweg-ID or buyer e-mail field fills BT-49 and your seller e-mail fills BT-34; the studio checks both before export.

Buyer reference missing (BR-DE-15)

XRechnung always requires a buyer reference (BT-10). For public-sector buyers this is the Leitweg-ID, which routes the invoice to the right accounting office; without it the invoice is rejected even when everything else is right.

Business customers have no Leitweg-ID, but the field stays mandatory under the XRechnung profile. Enter the reference your customer gave you, such as a purchase order number, cost centre or customer number. Ask once per customer and keep it in the customer record.

Seller contact and addresses (BR-DE-2 to BR-DE-9)

XRechnung makes data mandatory that the standard leaves optional. BR-DE-2 requires a seller contact group (BG-6), and BR-DE-5, BR-DE-6 and BR-DE-7 a contact name (BT-41), phone number (BT-42) and e-mail address (BT-43) inside it. Follow-up rules also check the format: a phone number needs at least three digits, an e-mail address an @.

BR-DE-3 and BR-DE-4 require the seller's city (BT-37) and post code (BT-38), BR-DE-8 and BR-DE-9 the same for the buyer (BT-52, BT-53). These errors nearly always appear together when an address was passed as a single line of text rather than separate fields.

Payment details and early-payment discount (BR-DE-1, BR-DE-18)

BR-DE-1 requires payment instructions (BG-16): at least a payment means code — typically 58 for SEPA credit transfer or 30 for a generic credit transfer — and, for a transfer, the payee's IBAN (BT-84). A formally invalid IBAN is reported as a warning.

Early-payment discount (Skonto) is a special case: XRechnung expects it in the payment terms (BT-20) in a fixed syntax, for example #SKONTO#TAGE=14#PROZENT=2.00#, each on its own line and ending with a line break. Free text such as “2% discount if paid within 14 days” violates BR-DE-18.

Totals don't add up (BR-CO-10, BR-CO-15, BR-CO-25)

BR-CO-10 checks that the sum of line net amounts equals the invoice net total (BT-106). BR-CO-15 checks that the gross amount (BT-112) is exactly net plus VAT. Both rules work to the cent.

The usual cause is rounding: rounding VAT per line and then adding it up often differs by a cent from VAT calculated on the taxable amount. Calculate VAT per rate on the sum of the lines and round once. Also produce the PDF and the XML from the same data — an amount changed later in only one of them is a common source of mismatches.

BR-CO-25 requires either a due date (BT-9) or payment terms (BT-20) when the amount due is positive. A short sentence such as “Payable within 14 days” is enough.

Exemption, reverse charge and small businesses (BR-E-10, BR-AE-10, BR-DE-16)

Every VAT category without VAT needs an exemption reason: BR-E-10 for exempt supplies (category E), BR-AE-10 for reverse charge (category AE). Add a text (BT-120) or a code (BT-121) to the VAT breakdown, such as “Reverse charge”. Reverse charge also requires the VAT IDs of both seller and buyer.

German small businesses under § 19 UStG use category E with an exemption note. BR-DE-16 then requires the seller's tax number (BT-32) when there is no VAT ID (BT-31). In the Toolula studio the small-business option sets the category and note automatically and asks for the tax number.

Wrong specification identifier (BR-DE-21)

The specification identifier (BT-24, cbc:CustomizationID in UBL) tells the validator which rule set applies. For XRechnung 3.0 it is urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0. An outdated identifier, for example from XRechnung 2.x, or the plain EN 16931 identifier triggers BR-DE-21 — often with a long tail of follow-up errors because the wrong rule set is being applied.

So when the error list is long, check the identifier first. Once it is right, several messages often disappear at once.

A short check before you send

Open the finished file once in the Toolula E-Invoice Reader before sending it. It shows the invoice in readable form, flags missing required fields and checks that the totals add up — locally in your browser, with no upload. That catches most typos and arithmetic errors.

For a binding check before submitting to a public authority, also run the official KoSIT validator with the current XRechnung configuration; many submission portals run the same check on upload. Keep each customer's invoicing data clean — Leitweg-ID or reference, invoice e-mail, address in separate fields — and most of these errors never occur.

Frequently asked questions