PEPPOL-COMMON-R040 The Seller electronic address (BT-34) is "7300010000002" under scheme "0088", which identifies the GS1 Global Location Number
The Seller electronic address (BT-34) is "7300010000002" under scheme "0088", which identifies the GS1 Global Location Number. A value in that scheme must be digits only, with a GS1 mod-10 check digit in the last position, and this one is not. A GLN is self-checking by design: the final digit closes a weighted sum to a multiple of ten, which is what lets a scanner reject a misread barcode rather than route a pallet to the wrong dock. The same digit rejects a mistyped invoice address here, before an access point tries to resolve it. Peppol flags this fatal: the identifier is what an access point resolves to find your counterparty, so a value that fails its own check digit is undeliverable. This is a Peppol BIS Billing 3.0 profile rule: it applies because profile is "peppol-bis-3". It does not apply to the en16931, xrechnung-ubl or xrechnung-cii profiles, whose validators will accept the same document.
This rule is implemented and its error payload below is real, but the long-form write-up — normative text, worked example, divergence note — is not written yet. Everything the library knows about this rule is on this page. Ask and we will prioritise it.
- Business term
BT-34- Severity
fatal
What the library returns
The exact object in result.errors when this rule fires.
Generated by running @attestwire/en16931, not transcribed:
{
"rule": "PEPPOL-COMMON-R040",
"field": "BT-34",
"severity": "fatal",
"message": "The Seller electronic address (BT-34) is \"7300010000002\" under scheme \"0088\", which identifies the GS1 Global Location Number. A value in that scheme must be digits only, with a GS1 mod-10 check digit in the last position, and this one is not. A GLN is self-checking by design: the final digit closes a weighted sum to a multiple of ten, which is what lets a scanner reject a misread barcode rather than route a pallet to the wrong dock. The same digit rejects a mistyped invoice address here, before an access point tries to resolve it. Peppol flags this fatal: the identifier is what an access point resolves to find your counterparty, so a value that fails its own check digit is undeliverable. This is a Peppol BIS Billing 3.0 profile rule: it applies because profile is \"peppol-bis-3\". It does not apply to the en16931, xrechnung-ubl or xrechnung-cii profiles, whose validators will accept the same document.",
"fix": "Correct seller.electronicAddress, or change its scheme identifier if the value belongs to a different register. A check digit failing almost always means one digit was transposed or dropped in transcription — compare it against the source register rather than re-typing it.",
"example": "\"electronicAddress\": { \"schemeId\": \"0088\", \"value\": \"7300010000001\" }",
"xpath": "/ubl:Invoice/cac:AccountingSupplierParty/cac:Party/cbc:EndpointID",
"docsUrl": "https://attestwire.com/rules/PEPPOL-COMMON-R040"
}
xpath locates the element in the generated UBL document,
which is where a KoSIT or Peppol validator will report the same problem.
A passing value
"electronicAddress": { "schemeId": "0088", "value": "7300010000001" }The fix
Correct seller.electronicAddress, or change its scheme identifier if the value belongs to a different register. A check digit failing almost always means one digit was transposed or dropped in transcription — compare it against the source register rather than re-typing it.