PEPPOL-COMMON-R040: Fix a GLN whose check digit is wrong

The short answer

PEPPOL-COMMON-R040 fails when an identifier marked schemeID="0088", the GS1 Global Location Number scheme, is not a run of digits ending in the correct check digit. In the recorded example the buyer cbc:EndpointID is 7300010000002, and a GLN beginning with those twelve digits must end in 1.

A wrong check digit means the number was mistyped or altered, not that its last digit needs recalculating. Get the correct GLN from the party it identifies; a number made to pass by changing its last digit may belong to someone else.

What the rule checks

Three kinds of element are covered: any cbc:EndpointID, any cac:PartyIdentification/cbc:ID and any cbc:CompanyID whose schemeID is exactly 0088. When tried, a wrong check digit was reported on the seller identifier and on the seller legal registration identifier as well as on an electronic address, once per element.

Surrounding spaces are removed, and what remains must be digits only. When tried, a space inside the number and a letter in place of the last digit both failed.

The last digit is compared with the GS1 modulo 10 check digit of the digits before it. The length is not checked: when tried, 07300010000001, fourteen digits, passed, because a leading zero adds nothing to the weighted sum.

Other identifiers with scheme 0088 are not examined. When tried, the same wrong check digit on a cac:StandardItemIdentification/cbc:ID or on a cac:DeliveryLocation/cbc:ID produced no finding.

How an integration ends up here

Possible causes, from the shape of the rule rather than from measured usage:

• The GLN was typed by hand from a letter, email or form, and a digit was changed on the way.
• A test or placeholder number was left in the party data and never replaced with the real GLN.
• A number from another scheme, such as a company registration number or an internal account number, is sent with schemeID="0088".
• The GLN is stored with spaces or hyphens for readability, as printed on labels.

How to fix it

1. Find the element from the finding location: an electronic address, a party identifier or a legal registration identifier.
2. Obtain the correct GLN from the party it identifies, or from its Peppol registration if it is an electronic address, and correct the stored value.
3. Write it as thirteen digits with no spaces or separators.
4. If the value is not a GLN at all, give it the schemeID of the scheme that did issue it instead of 0088.
5. Validate GLNs with the check digit calculation when party data is entered, so a mistyped number is caught before any invoice is built.

First twelve digits: 7 3 0 0 0 1 0 0 0 0 0 0
Weights:             1 3 1 3 1 3 1 3 1 3 1 3
Weighted sum: 7 + 9 + 0 + 0 + 0 + 3 + 0 + 0 + 0 + 0 + 0 + 0 = 19
Check digit: (10 - (19 mod 10)) mod 10 = (10 - 9) mod 10 = 1
7300010000001 ends in 1 and passes; 7300010000002 ends in 2 and fails

Validate your corrected invoice

Before and after

These are fragments, not complete documents. The complete synthetic documents they come from are linked below.

Fragment of the failing invoice: the buyer GLN ends in 2

<cac:AccountingCustomerParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000002</cbc:EndpointID>
    <!-- postal address and legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingCustomerParty>

Fragment of the corrected invoice: the buyer GLN ends in its check digit, 1

<cac:AccountingCustomerParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
    <!-- postal address and legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingCustomerParty>

Only the last digit of the buyer cbc:EndpointID differs: 7300010000002 in the failing invoice, 7300010000001 in the corrected one. PEPPOL-COMMON-R040 is the only finding, and the EN 16931 layer passes, since EN 16931 checks the scheme code of an electronic address but not the identifier under it.

Where it applies

• The check does not depend on the document type. When tried, a wrong check digit in the buyer address of a credit note reported this rule alone.
• A Peppol rule, reported on the Peppol layer only.
• The rule applies only when schemeID is exactly 0088. Under any other scheme the digits are not checked here, and the scheme code itself is judged by BR-CL-10 for a party identifier, BR-CL-11 for a legal registration identifier, and BR-CL-25 with PEPPOL-EN16931-CL008 for an electronic address.
• Passing shows the number is well formed. It does not show that GS1 issued it, that it belongs to the party, or that it is registered on the Peppol network.

Related rules

• PEPPOL-EN16931-CL008 checks the scheme code of an electronic address, which must be 0088 for this rule to apply
• BR-CL-10 checks the scheme code of a party identifier
• BR-CL-25 checks the electronic address scheme on the EN 16931 layer
• PEPPOL-EN16931-R010 requires the buyer electronic address that carries the GLN in the recorded example
• Browse every rule in the reference
• Background: How Peppol invoice validation actually works

Scope and source

Written for Peppol BIS Billing 3.0.21 (May 2026), EN 16931 1.3.16, as applied to UBL 2.1 Invoice and CreditNote documents. Other profiles, syntaxes and releases can define this identifier differently. Guidance version 2026-09-24.1: source checked 2026-09-24, explanation last updated 2026-09-24.

The official definition of PEPPOL-COMMON-R040 carries the normative wording and test. This page is our explanation of it, not a copy.

Guidance does not change the engine verdict. Fixing this finding does not mean the document passes every layer, and validation does not certify legal or tax compliance or transmit a document over Peppol.