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

An identifier with scheme `0088` must be all digits and end in the correct GS1 check digit. `7300010000001` passes; `7300010000002` does not.

- Layer: Peppol BIS Billing
- Severity: fatal (the document is invalid)
- Topics: Parties and addresses
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/PEPPOL-COMMON-R040/
- Explanation last updated: 2026-09-24

## 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.

| Term | Meaning | UBL element |
|---|---|---|
| BT-49 | Buyer electronic address (the element in the recorded example) | `cac:AccountingCustomerParty/cac:Party/cbc:EndpointID` |
| BT-34 | Seller electronic address | `cac:AccountingSupplierParty/cac:Party/cbc:EndpointID` |
| BT-29 | Seller identifier | `cac:AccountingSupplierParty/cac:Party/cac:PartyIdentification/cbc:ID` |
| BT-30 | Seller legal registration identifier | `cac:AccountingSupplierParty/cac:Party/cac:PartyLegalEntity/cbc:CompanyID` |

## 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.

The check digit of 7300010000001, the value in the corrected invoice. Weights 3 and 1 alternate leftwards from the digit next to the check digit, so for a thirteen-digit GLN they run 1, 3, 1, 3 from the left.

```text
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
```

## 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

```xml
<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

```xml
<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.

### What the validator reported

- The failing invoice reports **PEPPOL-COMMON-R040**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/PEPPOL-COMMON-R040-invalid.xml)
  - [Download the corrected XML](https://ironfang.uk/finance/rule-examples/invoice-minimal.xml)

Recorded on phive 12.1.0 / phive-rules-peppol 4.5.6 / Saxon-HE 12.10, the engine behind the free validator, using synthetic data. A recorded result is regression evidence for these documents; it is not a certification.

## 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](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-CL008.md)
- [BR-CL-10 checks the scheme code of a party identifier](https://ironfang.uk/docs/finance/rules/BR-CL-10.md)
- [BR-CL-25 checks the electronic address scheme on the EN 16931 layer](https://ironfang.uk/docs/finance/rules/BR-CL-25.md)
- [PEPPOL-EN16931-R010 requires the buyer electronic address that carries the GLN in the recorded example](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R010.md)

## 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](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/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.

## Links

- [This rule as a web page](https://ironfang.uk/docs/finance/rules/PEPPOL-COMMON-R040)
- [Free Peppol invoice validator](https://ironfang.uk/tools/peppol-validator)
- [Rule index](https://ironfang.uk/docs/finance/rules.md)
- [Ironfang Finance API docs](https://ironfang.uk/docs/finance)
- The same rule is available to MCP clients as the tool `finance.rule.get` on https://mcp.ironfang.uk/mcp