einvoice / EN 16931 / XRechnung rule reference

BR-DE-3

So beheben Sie den Fehler

Das Element "Seller city" (BT-37) muss übermittelt werden.

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

Seller city (BT-37) must be transmitted (non-empty).

Requires
Seller city (BT-37) must be transmitted (non-empty).
Business terms
BT-37
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:PostalAddress
Fix (Deutsch)
Ergänzen Sie das erforderliche Element bei `/ubl:Invoice/cac:AccountingSupplierParty/cac:Party/cac:PostalAddress`: Das Element "Seller city" (BT-37) muss übermittelt werden.
Fix
Add the required element at `/ubl:Invoice/cac:AccountingSupplierParty/cac:Party/cac:PostalAddress`: Seller city (BT-37) must be transmitted (non-empty).
Severity
fatal
Provenance source
xrechnung-ubl
Provenance assert

Das Element "Seller city" (BT-37) 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-3 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-3 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-3 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:PostalAddress element of the vendored UBL instance 01.06_minimal_test_ubl.xml, with exactly one change: its cbc:CityName child is emptied — the element stays in the document, its text is gone.

<cac:PostalAddress>
  <cbc:CityName></cbc:CityName>
  <cbc:PostalZone>12345</cbc:PostalZone>
  <cac:Country>
    <cbc:IdentificationCode>DE</cbc:IdentificationCode>
  </cac:Country>
</cac:PostalAddress>

UBL — passes

<cac:PostalAddress>
  <cbc:CityName>[Seller city]</cbc:CityName>
  <cbc:PostalZone>12345</cbc:PostalZone>
  <cac:Country>
    <cbc:IdentificationCode>DE</cbc:IdentificationCode>
  </cac:Country>
</cac:PostalAddress>

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

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

<ram:PostalTradeAddress>
<!-- BT-38 -->
    <ram:PostcodeCode>12345</ram:PostcodeCode>
<!-- BT-37 -->
    <ram:CityName></ram:CityName>
<!-- BT-40 -->
    <ram:CountryID>DE</ram:CountryID>
</ram:PostalTradeAddress>

CII — passes

<ram:PostalTradeAddress>
<!-- BT-38 -->
    <ram:PostcodeCode>12345</ram:PostcodeCode>
<!-- BT-37 -->
    <ram:CityName>[Seller city]</ram:CityName>
<!-- BT-40 -->
    <ram:CountryID>DE</ram:CountryID>
</ram:PostalTradeAddress>

The CII run reports BR-DE-3 at ram:SellerTradeParty/ram:PostalTradeAddress/ram:CityName 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:CityName value at cac:AccountingSupplierParty/cac:Party/cac:PostalAddress/cbc:CityName across the 43 vendored UBL instances this engine grades clean, 43 of which carry the element:

CII — every distinct ram:CityName value at rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:SellerTradeParty/ram:PostalTradeAddress/ram:CityName across the 39 vendored CII instances this engine grades clean, 39 of which carry the element:

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, 37 carry cbc:CityName here and 4 do not. Re-graded under --profile xrechnung, issue116.xml — a clean EN 16931 invoice — reports BR-DE-1 BR-DE-2 BR-DE-21 BR-DE-3 BR-DE-4 BR-DE-8 BR-DE-9, BR-DE-3 among them.

The 18 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-3 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:PostalAddress | /cn:CreditNote/cac:AccountingSupplierParty/cac:Party/cac:PostalAddress
UBL assert
cbc:CityName[boolean(normalize-space(.))]
CII context
/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:SellerTradeParty/ram:PostalTradeAddress
CII assert
ram:CityName[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:PostalAddress 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: