Check an XRechnung invoice and understand its errors

a German invoice, and the handful of fields that sink it.

A German customer, most likely a public body, has refused your invoice, and the message names a rule and a field. You have not done anything unusual: German public bodies require a few fields that the rest of Europe treats as optional, and most refusals come down to one of those fields being empty. This page lists every German rule, says what each one asks for, and lets you check your file in your browser before you send it again.

The names in the message follow one pattern. EN 16931 is the European standard that says what an electronic invoice must contain, and XRechnung is Germany's version of it, which German public bodies require. Every field in an invoice has a number in that standard (the buyer reference is field 10, written BT-10), and every check has a name (BR-DE-15 is the rule that looks for the buyer reference).

Find the rule name from your message in the table below, read what it asks for, add or correct the field, and check the file again.

The rejection you are probably holding

A German portal answers with the rule name and the field, in German, and stops there:

[BR-DE-15]-Das Element "Buyer reference" (BT-10) muss übermittelt werden.

Here is the same failure from Attestwire. It names the same rule, and adds the field, what the regulation wants, the value to set and a page to read:

{
  "rule": "BR-DE-15",
  "field": "BT-10",
  "severity": "fatal",
  "message": "XRechnung requires a buyer reference (BT-10). For German public-sector buyers this is the Leitweg-ID; business buyers may supply any reference, but the field must be present.",
  "fix": "Ask your client for their Leitweg-ID (public sector) or an order/customer reference, and set buyerReference.",
  "example": "\"buyerReference\": \"04011000-1234512345-06\"",
  "xpath": "/ubl:Invoice/cbc:BuyerReference",
  "docsUrl": "https://attestwire.com/rules/BR-DE-15"
}

What XRechnung adds on top of core EN 16931

XRechnung is a national add-on to EN 16931 (the formal term is CIUS) that makes optional fields mandatory. The list below was produced by running the engine rather than by copying a specification. Take an invoice that passes core EN 16931 with no findings at any severity, change one field to profile: "xrechnung-ubl", and run it again. 3 rules now fail:

• BR-DE-15 (BT-10) — Ask your client for their Leitweg-ID (public sector) or an order/customer reference, and set buyerReference.
• BR-DE-1 (BG-16) — Set payment.meansCode to a UNTDID 4461 code: "58" SEPA credit transfer, "30" credit transfer, "59" SEPA direct debit, "48" card, "57" standing agreement, "97" clearing between partners. Each code obliges its own group: for 30/58 set payment.iban (BG-17), for 59 set payment.directDebit (BG-19), for 48/54/55 set payment.card (BG-18).
• BR-DE-2 (BG-6) — Set seller.contact with all three of name, phone and email. A shared departmental identity is fine and usually preferable to a named individual.

Those are the German additions for this invoice, and each is a field you can set today: a buyer reference, payment instructions, and a complete seller contact. The same run also raises 2 warnings from Peppol, the network many European buyers receive invoices through, about the electronic address. That is the field a routing network needs, and a German portal will ask about it sooner or later.

Your own invoice will differ in the details, but the shape is the same: the German add-on does not change what an invoice means, it makes optional fields mandatory.

Every BR-DE rule, with a page each

31 rules carry the BR-DE prefix in this build, 24 of them fatal and the rest warnings and advisories. Each name links to a permanent page with the official text, why the rule exists, the field to change and a passing example. It is the same page the docsUrl on a finding points at, so an error in your log gets you there in one click.

Severities are those of the official XRechnung checker published by KoSIT, the German office responsible for it. fatal: Rejects the document. warning: Raised, and the document is still accepted. information: Advisory. Never blocks anything. The whole rule reference, all profiles

What KoSIT said about our own output

KoSIT, the German government’s validator, accepts all eleven sample invoices this library generates. One of them draws a warning from a European rule that KoSIT itself has marked as broken and replaced; it passes the replacement. None draws an error. Validator 1.6.3, XRechnung configuration 3.0.2 (build of 31 August 2026), CEN CII schematron 1.3.16, XRechnung CII schematron 2.6.0; recorded 24 September 2026 against engine 0.10.0.

The warning is CII-SR-475 on the extended CII fixture, a rule that miscounts attachments when an invoice has more than one (CEN issue 508). KoSIT’s configuration lowers it to information and checks BR-TMP-4 instead, which passes.

That is evidence about those 11 generated fixtures. It is not a parity suite, and it is not a guarantee that any particular receiver will accept your document. Documents you check are not run through KoSIT at request time.

The run in full: commands, versions, the per-fixture table · How current the rule artefacts are

UBL or CII?

UBL and CII are the two XML file formats an EN 16931 invoice can be written in, and XRechnung allows both. This build writes and reads both: xrechnung-ubl and xrechnung-cii. The rules and the findings are the same; only the file differs. Send whichever your receiver asked for. If nobody said, UBL is the safer default in Germany.

One boundary to know before you pick xrechnung-cii: CII is also the format inside a ZUGFeRD or Factur-X PDF (a PDF invoice with the XML invoice attached inside it), and what we generate is the XML, never the PDF/A-3 container. The exact rule on PDF, in both directions

How the two syntaxes differ, and how to tell which one you are holding

Try it on an invoice

The sample in the playground is a real XRechnung with one field taken out. Fix the field, generate the XML, and watch the finding disappear. Or switch tabs and paste your own file instead, which is checked in your browser and never uploaded.

Check your invoice in the playground

Questions people ask next

Is XRechnung mandatory in Germany?

For invoicing German public-sector buyers, yes: XRechnung is the standard those contracting authorities receive. For business-to-business invoices the picture is a calendar: receiving domestic B2B e-invoices has been mandatory since January 2025. Issuing starts 1 January 2027 above €800,000 prior-year turnover, 1 January 2028 for everyone else. XRechnung is one conformant way to meet that. The obligation is to EN 16931, not to this profile specifically. What we do and do not cover

XRechnung or ZUGFeRD — which one do I need?

Ask your buyer, because they are different deliverables. XRechnung is a pure XML document, and it is what German public-sector buyers ask for. ZUGFeRD (and its French twin Factur-X) is a PDF/A-3 file with CII XML attached inside it, which suits a buyer who wants something a human can also read.

Attestwire writes the XML for both and builds the PDF container for neither: for ZUGFeRD you take our CII payload to a PDF/A-3 library. Reading goes the other way: extractFacturX opens an existing ZUGFeRD or Factur-X PDF and hands back the XML inside it.

How do I validate an XRechnung file?

Paste it into the playground and you get findings in the browser. In code, read the file with parseUbl or parseCiiInvoice and pass the result to validateInput; over HTTP, POST it to the hosted API as application/xml. All three run the same rules and return the same findings. For a binding verdict you still want KoSIT's own validator, which is the German authority and which we run our fixtures through.

Can I validate XRechnung without uploading it?

Yes, and that is the default. The playground runs the engine as a module inside your browser tab, so no request carrying your document leaves the page. The npm package and the GitHub Action do the same thing on your own machine, offline and with no key. The hosted API is the one door that receives the document, and it processes payloads in memory without storing them.

What does the Leitweg-ID have to do with BR-DE-15?

BR-DE-15 requires a buyer reference (BT-10) on every XRechnung. For a German public-sector buyer that reference is the Leitweg-ID, the routing identifier the authority issues you, so a missing Leitweg-ID and a failed BR-DE-15 are usually the same problem. A business buyer may put any order or customer reference in the field; what the rule will not accept is the field being absent. The rule page has a passing example