einvoice / EN 16931 / XRechnung rule reference

BR-CL-26

What this rule means and how to fix it

Delivery location identifier scheme identifier MUST belong to the ISO 6523 ICD code list.

Die Kennung des Schemas der Kennung des Lieferorts MUSS der Codeliste ISO 6523 ICD angehören.

Deutsche Fassung: Übersetzung der gleichen BT/BG-Semantik (translation — not the official assert).

Requires
Delivery location identifier scheme identifier MUST belong to the ISO 6523 ICD code list
Business terms
— (no single business term)
Syntax
Binds the UBL-2.1 Invoice / CreditNote syntax and the UN/CEFACT-CII syntax
Location (UBL-2.1 path)
cac:DeliveryLocation/cbc:ID[@schemeID]
Fix
Encode `cac:DeliveryLocation/cbc:ID[@schemeID]` using a valid value from ISO 6523 ICD code list.
Fix (Deutsch)
Codieren Sie `cac:DeliveryLocation/cbc:ID[@schemeID]` mit einem gültigen Wert aus der geforderten Codeliste: Die Kennung des Schemas der Kennung des Lieferorts MUSS der Codeliste ISO 6523 ICD angehören.
Severity
fatal
Provenance source
en16931-ubl
Provenance assert

Delivery location identifier scheme identifier MUST belong to the ISO 6523 ICD 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 CEN EN 16931 1.3.16 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-CL-26 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-CL-26 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/cen-en16931/test/testfiles/Invoice-Max_content.xml under --profile en16931, 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 ID was changed from 0088 to ZZZ, a token that appears in no code list. The page publishes it because the engine reported BR-CL-26 for the edited document and did not report it for the untouched one.

UBL Invoice — fails

The vendored file around the change, verbatim:

<cac:Delivery>
	<cbc:ActualDeliveryDate>2017-12-01</cbc:ActualDeliveryDate>
	<cac:DeliveryLocation>
		<cbc:ID schemeID="ZZZ">7350000001211</cbc:ID>
		<cac:Address>
			<cbc:StreetName>DELIV Streetname-line1</cbc:StreetName>
			<cbc:AdditionalStreetName>DELIV AddStreetname-line2</cbc:AdditionalStreetName>
			<cbc:CityName>DELIV Town</cbc:CityName>
			<cbc:PostalZone>DELIV 90807</cbc:PostalZone>
			<cbc:CountrySubentity>DELIV Delstat C</cbc:CountrySubentity>
			<cac:AddressLine>
				<cbc:Line>DELIV-line3</cbc:Line>
			</cac:AddressLine>
			<cac:Country>
				<cbc:IdentificationCode>SE</cbc:IdentificationCode>
			</cac:Country>
		</cac:Address>
	</cac:DeliveryLocation>
	<cac:DeliveryParty>
		<cac:PartyName>
			<cbc:Name>Deliver-to Name A.S.</cbc:Name>
		</cac:PartyName>
	</cac:DeliveryParty>
</cac:Delivery>

UBL Invoice — passes

The same lines as Invoice-Max_content.xml actually ships them — this block is the fix for the block above:

<cac:Delivery>
	<cbc:ActualDeliveryDate>2017-12-01</cbc:ActualDeliveryDate>
	<cac:DeliveryLocation>
		<cbc:ID schemeID="0088">7350000001211</cbc:ID>
		<cac:Address>
			<cbc:StreetName>DELIV Streetname-line1</cbc:StreetName>
			<cbc:AdditionalStreetName>DELIV AddStreetname-line2</cbc:AdditionalStreetName>
			<cbc:CityName>DELIV Town</cbc:CityName>
			<cbc:PostalZone>DELIV 90807</cbc:PostalZone>
			<cbc:CountrySubentity>DELIV Delstat C</cbc:CountrySubentity>
			<cac:AddressLine>
				<cbc:Line>DELIV-line3</cbc:Line>
			</cac:AddressLine>
			<cac:Country>
				<cbc:IdentificationCode>SE</cbc:IdentificationCode>
			</cac:Country>
		</cac:Address>
	</cac:DeliveryLocation>
	<cac:DeliveryParty>
		<cac:PartyName>
			<cbc:Name>Deliver-to Name A.S.</cbc:Name>
		</cac:PartyName>
	</cac:DeliveryParty>
</cac:Delivery>

What the engine reports for the edited invoice

{
  "element": "cac:DeliveryLocation/cbc:ID/@schemeID",
  "field": "cac:DeliveryLocation/cbc:ID/@schemeID",
  "fix_hint": "Encode `cac:DeliveryLocation/cbc:ID[@schemeID]` using a valid value from ISO 6523 ICD code list.",
  "location": "cac:DeliveryLocation/cbc:ID[@schemeID]",
  "message": "Delivery location identifier scheme identifier MUST belong to the ISO 6523 ICD code list; 'ZZZ' is not a listed ICD.",
  "rule": "BR-CL-26",
  "severity": "fatal",
  "terms": [],
  "title": "Delivery location identifier scheme identifier MUST belong to the ISO 6523 ICD code list."
}

Rule ids the engine reports for Invoice-Max_content.xml untouched: none. After the edit, BR-CL-26 is reported that was not before.

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/cen-en16931/test/testfiles/Invoice-Max_content.xml from this repository, apply the one edit named above, and run einvoice validate Invoice-Max_content.xml --profile en16931 --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: