einvoice / EN 16931 / XRechnung rule reference

BR-DE-28

So beheben Sie den Fehler

In BT-43 soll genau ein @-Zeichen enthalten sein, welches nicht von einem Leerzeichen, einem Punkt, aber mindestens zwei Zeichen auf beiden Seiten flankiert werden soll. Ein Punkt sollte nicht am Anfang oder am Ende stehen.

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

BT-43 should look like an email address (exactly one '@', flanked per the official regex).

Requires
BT-43 should look like an email address (exactly one '@', flanked per the official regex).
Business terms
BT-43
Syntax
Binds the UBL-2.1 Invoice / CreditNote syntax and the UN/CEFACT-CII syntax
Location (UBL-2.1 path)
/ubl:Invoice/cac:AccountingSupplierParty/cac:Party/cac:Contact
Fix (Deutsch)
Korrigieren Sie `/ubl:Invoice/cac:AccountingSupplierParty/cac:Party/cac:Contact`, sodass gilt: In BT-43 soll genau ein @-Zeichen enthalten sein, welches nicht von einem Leerzeichen, einem Punkt, aber mindestens zwei Zeichen auf beiden Seiten flankiert werden soll. Ein Punkt sollte nicht am Anfang oder am Ende stehen.
Fix
Correct `/ubl:Invoice/cac:AccountingSupplierParty/cac:Party/cac:Contact` so that BT-43 should look like an email address (exactly one '@', flanked per the official regex).
Severity
warning
Provenance source
xrechnung-ubl
Provenance assert

In BT-43 soll genau ein @-Zeichen enthalten sein, welches nicht von einem Leerzeichen, einem Punkt, aber mindestens zwei Zeichen auf beiden Seiten flankiert werden soll. Ein Punkt sollte nicht am Anfang oder am Ende stehen.

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-28 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-28 once the edit lands.

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/technical-cases/cius/01.06_minimal_test_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 text content of ElectronicMail was deleted, leaving the element present but empty. The page publishes it because the engine reported BR-DE-28 for the edited document and did not report it for the untouched one.

UBL Invoice — fails

The vendored file around the change, verbatim:

<cac:Contact>
  <cbc:Name>Tim Tester</cbc:Name>
  <cbc:Telephone>012 3456789</cbc:Telephone>
  <cbc:ElectronicMail></cbc:ElectronicMail>
</cac:Contact>

UBL Invoice — passes

The same lines as 01.06_minimal_test_ubl.xml actually ships them — this block is the fix for the block above:

<cac:Contact>
  <cbc:Name>Tim Tester</cbc:Name>
  <cbc:Telephone>012 3456789</cbc:Telephone>
  <cbc:ElectronicMail>tim.tester@test.com</cbc:ElectronicMail>
</cac:Contact>

What the engine reports for the edited invoice

{
  "element": "cac:AccountingSupplierParty/cac:Party/cac:Contact/cbc:ElectronicMail",
  "field": "cac:AccountingSupplierParty/cac:Party/cac:Contact/cbc:ElectronicMail",
  "fix_hint": "Correct `/ubl:Invoice/cac:AccountingSupplierParty/cac:Party/cac:Contact` so that BT-43 should look like an email address (exactly one '@', flanked per the official regex).",
  "location": "/ubl:Invoice/cac:AccountingSupplierParty/cac:Party/cac:Contact",
  "message": "'Seller contact email address' (BT-43) should contain exactly one '@' with valid flanking characters.",
  "rule": "BR-DE-28",
  "severity": "warning",
  "terms": [
    "BT-43"
  ],
  "title": "BT-43 should look like an email address (exactly one '@', flanked per the official regex)."
}

Rule ids the engine reports for 01.06_minimal_test_ubl.xml untouched: BR-DE-TMP-32. After the edit, BR-DE-28 BR-DE-7 are reported that were not before — one mechanical edit can break more than one rule at a time, and BR-DE-7 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/technical-cases/cius/01.06_minimal_test_ubl.xml from this repository, apply the one edit named above, and run einvoice validate 01.06_minimal_test_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: