einvoice / EN 16931 / XRechnung rule reference

BR-DE-7

So beheben Sie den Fehler

Das Element "Seller contact email address" (BT-43) muss übermittelt werden.

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

Seller contact email address (BT-43) must be transmitted.

Requires
Seller contact email address (BT-43) must be transmitted.
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)
Ergänzen Sie das erforderliche Element bei `/ubl:Invoice/cac:AccountingSupplierParty/cac:Party/cac:Contact`: Das Element "Seller contact email address" (BT-43) muss übermittelt werden.
Fix
Add the required element at `/ubl:Invoice/cac:AccountingSupplierParty/cac:Party/cac:Contact`: Seller contact email address (BT-43) must be transmitted.
Severity
fatal
Provenance source
xrechnung-ubl
Provenance assert

Das Element "Seller contact email address" (BT-43) 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-7 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-7 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-7 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 cac:Contact element of the vendored UBL instance 01.06_minimal_test_ubl.xml, with exactly one change: its cbc:ElectronicMail child is emptied — the element stays in the document, its text is gone.

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

UBL — passes

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

An element that is present but empty is not a pass here: the vendored assert is cbc:ElectronicMail[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": "cac:AccountingSupplierParty/cac:Party/cac:Contact/cbc:ElectronicMail",
  "field": "cac:AccountingSupplierParty/cac:Party/cac:Contact/cbc:ElectronicMail",
  "fix_hint": "Add the required element at `/ubl:Invoice/cac:AccountingSupplierParty/cac:Party/cac:Contact`: Seller contact email address (BT-43) must be transmitted.",
  "location": "/ubl:Invoice/cac:AccountingSupplierParty/cac:Party/cac:Contact",
  "message": "The element 'Seller contact email address' (BT-43) must be transmitted.",
  "rule": "BR-DE-7",
  "severity": "fatal",
  "terms": [
    "BT-43"
  ],
  "title": "Seller contact email address (BT-43) must be transmitted."
}

Rule ids reported for the failing document: BR-DE-28 BR-DE-7. 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:DefinedTradeContact element of the vendored CII instance 01.06_minimal_test_uncefact.xml, with exactly one change: its ram:EmailURIUniversalCommunication/ram:URIID child is emptied — the element stays in the document, its text is gone.

<ram:DefinedTradeContact>
<!-- BT-41 -->
    <ram:PersonName>Tim Tester</ram:PersonName>
<!-- BT-42 -->
    <ram:TelephoneUniversalCommunication>
        <ram:CompleteNumber>012 3456789</ram:CompleteNumber>
    </ram:TelephoneUniversalCommunication>
<!-- BT-43 -->
    <ram:EmailURIUniversalCommunication>
        <ram:URIID></ram:URIID>
    </ram:EmailURIUniversalCommunication>
</ram:DefinedTradeContact>

CII — passes

<ram:DefinedTradeContact>
<!-- BT-41 -->
    <ram:PersonName>Tim Tester</ram:PersonName>
<!-- BT-42 -->
    <ram:TelephoneUniversalCommunication>
        <ram:CompleteNumber>012 3456789</ram:CompleteNumber>
    </ram:TelephoneUniversalCommunication>
<!-- BT-43 -->
    <ram:EmailURIUniversalCommunication>
        <ram:URIID>tim.tester@test.com</ram:URIID>
    </ram:EmailURIUniversalCommunication>
</ram:DefinedTradeContact>

The CII run reports BR-DE-7 at ram:SellerTradeParty/ram:DefinedTradeContact/ram:EmailURIUniversalCommunication/ram:URIID 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:ElectronicMail value at cac:AccountingSupplierParty/cac:Party/cac:Contact/cbc:ElectronicMail 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:URIID, 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, 18 carry cbc:ElectronicMail here and 23 do not. Re-graded under --profile xrechnung, BIS_Billing_30-Inkopskort.xml — a clean EN 16931 invoice — reports BR-DE-14 BR-DE-21 BR-DE-28 BR-DE-5 BR-DE-7, BR-DE-7 among them.

The 14 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-7 cannot catch an exporter that writes the wrong field into it.

The rule as the vendored Schematron states it

UBL context
/ubl:Invoice/cac:AccountingSupplierParty/cac:Party/cac:Contact | /cn:CreditNote/cac:AccountingSupplierParty/cac:Party/cac:Contact
UBL assert
cbc:ElectronicMail[boolean(normalize-space(.))]
CII context
/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:SellerTradeParty/ram:DefinedTradeContact
CII assert
ram:EmailURIUniversalCommunication/ram:URIID[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 cac:Contact 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: