BR-DE-15 XRechnung requires a buyer reference
The German XRechnung CIUS makes BT-10 mandatory. For public-sector buyers that means the Leitweg-ID; for business buyers, any reference you agreed. It just cannot be absent.
- Business term
BT-10— Buyer reference- Severity
fatal- Applies to
xrechnung-ubl, xrechnung-cii
What the rule requires
Under the German CIUS XRechnung, business term BT-10 (Buyer reference) has to be present. In core EN 16931 it is optional, and XRechnung tightens it to mandatory — which is exactly what that BR-DE- prefix is telling you. This is a German national restriction, not a European rule.
If your buyer is a German public-sector body, BT-10 carries the Leitweg-ID: the routing identifier that tells the federal or state invoice portal which authority this document belongs to. It looks like 04011000-1234512345-06 — a coarse address, a fine address and a check digit. Important: the buyer issues it. You cannot derive it or make one up.
For a private-sector buyer who has simply asked you for XRechnung, this is easier than it sounds: any reference the two of you agreed will satisfy the rule — a purchase-order number, a contract number, a customer number.
Das Element „Buyer reference“ (BT-10) muss übermittelt werden.
Why it exists
German authorities do not route invoices by recipient name or VAT number. The Leitweg-ID is the routing key inside the ZRE and OZG-RE portals, so an XRechnung without BT-10 has nowhere to be delivered — it gets rejected at intake rather than landing in front of a human who might have worked it out. Making the field mandatory in the CIUS pulls that failure forward to a point where you can still do something about it, which is the whole idea.
What the library returns
The exact object in result.errors when this rule fires.
Generated by running @attestwire/en16931, not transcribed:
{
"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"
}
xpath locates the element in the generated UBL document,
which is where a KoSIT or Peppol validator will report the same problem.
Failing and passing
validateInput({
profile: "xrechnung-ubl",
invoiceNumber: "2026-000142",
issueDate: "2026-08-09",
currency: "EUR",
// buyerReference omitted <- BR-DE-15
seller: { /* ... */ },
buyer: { /* ... */ },
lines: [ /* ... */ ],
});
// -> { valid: false, errors: [ { rule: "BR-DE-15", ... } ] }validateInput({
profile: "xrechnung-ubl",
invoiceNumber: "2026-000142",
issueDate: "2026-08-09",
currency: "EUR",
buyerReference: "04011000-1234512345-06",
seller: { /* ... */ },
buyer: { /* ... */ },
lines: [ /* ... */ ],
});
// -> { valid: true, errors: [] }The fix, in plain English
Capture the buyer reference at onboarding rather than at invoicing time — it is a property of the customer, not of the invoice, and chasing it at 5pm on a billing run is nobody’s idea of fun. Add a required field to your German customer records and store the Leitweg-ID verbatim, hyphens and all, because some portals compare it as a literal string. If your contact does not know theirs, their accounts-payable or procurement desk will.
How our check differs
One limit to be clear about: our check is presence-only. It does not validate the Leitweg-ID’s structure or its check digit, so a typo will sail past us and get rejected later by the portal. Read a green result as “the field is filled in”, not “the routing ID is correct”.