einvoice / EN 16931 / XRechnung rule reference

BR-DE-15

So beheben Sie den Fehler

Das Element "Buyer reference" (BT-10) muss übermittelt werden.

Deutsche Fassung: Amtlicher KoSIT-Text (official KoSIT assert text).

Buyer reference (BT-10) must be transmitted (non-empty).

Requires
Buyer reference (BT-10) must be transmitted (non-empty).
Business terms
BT-10
Syntax
Binds the UBL-2.1 Invoice / CreditNote syntax and the UN/CEFACT-CII syntax
Location (UBL-2.1 path)
cbc:BuyerReference
Fix (Deutsch)
Ergänzen Sie das erforderliche Element bei `cbc:BuyerReference`: Das Element "Buyer reference" (BT-10) muss übermittelt werden.
Fix
Add the required element at `cbc:BuyerReference`: Buyer reference (BT-10) must be transmitted (non-empty).
Severity
fatal
Provenance source
xrechnung-ubl
Provenance assert

Das Element "Buyer reference" (BT-10) muss übermittelt werden.

The Location above is a UBL-2.1 path, and no UN/CEFACT-CII path for this rule is published here; Fix and Fix (Deutsch), verbatim from remediation_catalog.json and not reworded here; the UN/CEFACT-CII binding of this rule is differentially proven against the official KoSIT XRechnung 2.5.0 (XRechnung 3.0.2) Schematron.

Korrektur prüfen: Laden Sie die geänderte Rechnung in den Browser-Validator unter /einvoice/validate/ — er führt dieselbe Engine lokal im Browser aus, ohne Upload, und meldet BR-DE-15 nicht mehr, sobald die Korrektur greift.

Where to check the fix: paste the corrected invoice into the browser validator at /einvoice/validate/ — it runs this same engine locally in your browser, with no upload, and stops reporting BR-DE-15 once the edit lands.

The same invoice, failing and fixed

Neither block below is hand-written. Both are cut verbatim from a vendored KoSIT test instance — one this engine already grades clean under --profile xrechnung — at the element this rule's own Schematron context names. The failing variant is that element with one mechanical change, spliced back into the whole instance and re-graded: it is published only because the engine reported BR-DE-15 for the changed document and did not report it for the untouched one. Both official XRechnung syntaxes are shown, because the same rule id is asserted in each: UBL (the KoSIT default) and UN/CEFACT CII (the syntax inside a ZUGFeRD / Factur-X PDF).

UBL — fails

The cbc:BuyerReference element of the vendored UBL instance 01.06_minimal_test_ubl.xml, with exactly one change: cbc:BuyerReference is emptied — the element stays in the document, its text is gone.

<cbc:BuyerReference></cbc:BuyerReference>

UBL — passes

<cbc:BuyerReference>90000000-03083-72</cbc:BuyerReference>

An element that is present but empty is not a pass here: the vendored assert is cbc:BuyerReference[boolean(normalize-space(.))], and its normalize-space() test rejects an empty or whitespace-only value exactly as it rejects a missing element.

What the engine reports for the failing UBL invoice

{
  "element": "cbc:BuyerReference",
  "field": "cbc:BuyerReference",
  "fix_hint": "Add the required element at `cbc:BuyerReference`: Buyer reference (BT-10) must be transmitted (non-empty).",
  "location": "cbc:BuyerReference",
  "message": "The element 'Buyer reference' (BT-10) must be transmitted.",
  "rule": "BR-DE-15",
  "severity": "fatal",
  "terms": [
    "BT-10"
  ],
  "title": "Buyer reference (BT-10) must be transmitted (non-empty)."
}

Rule ids reported for the failing document: BR-DE-15. For the corrected document: none. (BR-DE-TMP-32, an information-level finding about the delivery date, is reported for both documents and is not affected by this edit.)

CII — fails

The ram:BuyerReference element of the vendored CII instance 01.06_minimal_test_uncefact.xml, with exactly one change: ram:BuyerReference is emptied — the element stays in the document, its text is gone.

<ram:BuyerReference></ram:BuyerReference>

CII — passes

<ram:BuyerReference>90000000-03083-72</ram:BuyerReference>

The CII run reports BR-DE-15 at ram:ApplicableHeaderTradeAgreement/ram:BuyerReference and, for the corrected document, none — the same rule id, a different syntax and a different element path.

What conformant invoices actually carry here

UBL — every distinct cbc:BuyerReference value at cbc:BuyerReference across the 43 vendored UBL instances this engine grades clean, 43 of which carry the element:

CII — the same corpus in the other syntax carries no value the UBL list above does not: 39 of the 39 clean CII instances fill ram:BuyerReference, out of the same set of values.

EN 16931 itself does not ask for this element — the German CIUS is what makes it mandatory, and the vendored CEN corpus shows the gap. Of the 41 CEN EN 16931 instances this engine grades clean under --profile en16931, 20 carry cbc:BuyerReference here and 21 do not. Re-graded under --profile xrechnung, guide-example1.xml — a clean EN 16931 invoice — reports BR-DE-15 BR-DE-2 BR-DE-21, BR-DE-15 among them.

The 10 distinct values that corpus carries at this element, most common first:

Note what those lists do not show: the assert tests non-emptiness and nothing else, so every value above passes. XRechnung places no constraint on the shape of this value, so BR-DE-15 cannot catch an exporter that writes the wrong field into it.

The rule as the vendored Schematron states it

UBL context
/ubl:Invoice | /cn:CreditNote
UBL assert
cbc:BuyerReference[boolean(normalize-space(.))]
CII context
/rsm:CrossIndustryInvoice
CII assert
rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:BuyerReference[boolean(normalize-space(.))]
Artifact
corpus/xrechnung-schematron/schematron/ubl/XRechnung-UBL-validation.sch

Reproduce it yourself: put the failing block into 01.06_minimal_test_ubl.xml in place of its cbc:BuyerReference element and run einvoice validate invoice.xml --profile xrechnung --format json, or paste the file into the browser validator, which runs the same engine locally with no upload.

Everything here is free and open source — pick up whatever helps, at your own pace: