einvoice / EN 16931 / XRechnung rule reference
BR-DEX-07
What this rule means and how to fix it
Any scheme identifier on an Endpoint identifier (cbc:Endpoint ID, BT-34/BT-49) must belong to the CEF EAS (extension) code list.
Jede Schema-Kennung einer Endpunktkennung (cbc:EndpointID, BT-34/BT-49) muss der CEF-EAS-Codeliste (Extension) angehören.
Deutsche Fassung: Übersetzung der gleichen BT/BG-Semantik (translation — not the official assert).
- Requires
- any scheme identifier on an Endpoint identifier (cbc:Endpoint ID, BT-34/BT-49) must belong to the CEF EAS (extension) code list.
- Business terms
BT-34BT-49- Syntax
- Binds the UBL-2.1 Invoice / CreditNote syntax and the UN/CEFACT-CII syntax
- Location (UBL-2.1 path)
cbc:EndpointID[@schemeID and $isExtension]- Fix
- Correct `cbc:EndpointID[@schemeID and $isExtension]` so that any scheme identifier on an Endpoint identifier (cbc:Endpoint ID, BT-34/BT-49) must belong to the CEF EAS (extension) code list.
- Fix (Deutsch)
- Korrigieren Sie `cbc:EndpointID[@schemeID and $isExtension]`, sodass gilt: Jede Schema-Kennung einer Endpunktkennung (cbc:EndpointID, BT-34/BT-49) muss der CEF-EAS-Codeliste (Extension) angehören.
- Severity
- fatal
- Provenance source
xrechnung-ubl- Provenance assert
Any scheme identifier for an Endpoint Identifier in MUST belong to the CEF EAS code list.
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.
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-DEX-07 once the edit lands.
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-DEX-07 nicht mehr, sobald die Korrektur greift.
The same invoice, failing and fixed
No vendored test suite ships a labelled example for this rule, so this pair was found rather than written. The engine was run over the vendored instance corpus/xrechnung-testsuite/src/test/business-cases/extension/04.01a-INVOICE_ubl.xml under --profile xrechnung, then re-run over the same file with one mechanical edit applied to one element, over and over, until the edit below changed the verdict: the schemeID attribute of EndpointID was changed from EM to ZZZ, a token that appears in no code list. The page publishes it because the engine reported BR-DEX-07 for the edited document and did not report it for the untouched one.
UBL Invoice (XRechnung extension) — fails
The vendored file around the change, verbatim:
<cbc:EndpointID schemeID="ZZZ">seller@email.de</cbc:EndpointID>
UBL Invoice (XRechnung extension) — passes
The same lines as 04.01a-INVOICE_ubl.xml actually ships them — this block is the fix for the block above:
<cbc:EndpointID schemeID="EM">seller@email.de</cbc:EndpointID>
What the engine reports for the edited invoice
{
"element": "cbc:EndpointID/@schemeID",
"field": "cbc:EndpointID/@schemeID",
"fix_hint": "Correct `cbc:EndpointID[@schemeID and $isExtension]` so that any scheme identifier on an Endpoint identifier (cbc:Endpoint ID, BT-34/BT-49) must belong to the CEF EAS (extension) code list.",
"location": "cbc:EndpointID[@schemeID and $isExtension]",
"message": "Any scheme identifier on an 'Electronic address' endpoint (BT-34/BT-49) must belong to the CEF EAS code list.",
"rule": "BR-DEX-07",
"severity": "fatal",
"terms": [
"BT-34",
"BT-49"
],
"title": "Any scheme identifier on an Endpoint identifier (cbc:Endpoint ID, BT-34/BT-49) must belong to the CEF EAS (extension) code list."
}
Rule ids the engine reports for 04.01a-INVOICE_ubl.xml untouched: none. After the edit, BR-CL-25 BR-DEX-07 are reported that were not before — one mechanical edit can break more than one rule at a time, and BR-CL-25 is the neighbour this one takes with it.
Two honest limits. This is an edit that provokes the rule, not the only one, and it is not a claim about how real exporters break it. And it is the reverse of the fix a reader needs: the passing block is the vendored file's own content, which is what a conformant invoice looks like here.
Reproduce it yourself: take corpus/xrechnung-testsuite/src/test/business-cases/extension/04.01a-INVOICE_ubl.xml from this repository, apply the one edit named above, and run einvoice validate 04.01a-INVOICE_ubl.xml --profile xrechnung --format json, or paste the file into the browser validator, which runs this same engine locally with no upload.
Everything here is free and open source — pick up whatever helps, at your own pace:
- Licensing — free and open source under Apache-2.0 for everyone, including closed-source embedding: use, modify and ship it inside a commercial product with no fee and no license key.
- German remediation (
--lang de) — the German fix for this rule is in the section above; the CLI surfaces it in place of the English message with--lang de. - Quickstart / free on-ramp — the README, a copy-paste CI-gate recipe, and a 5-minute worked walkthrough.