PEPPOL-EN16931-CL008: Use a Peppol electronic address scheme code in EndpointID

The short answer

PEPPOL-EN16931-CL008 fails when the schemeID of a cbc:EndpointID is not, character for character, one of the scheme codes Peppol accepts for electronic addresses. In the recorded example the seller address is marked GLN; the code for a GLN is 0088.

The EN 16931 rule BR-CL-25 tests the same attribute against the EAS list. A value that neither list contains, like GLN, is reported by both rules. Every code on the Peppol list is also on the EAS list, so a code Peppol accepts satisfies both.

What the rule checks

The rule runs on every cbc:EndpointID that has a schemeID attribute, and the finding points at that element. An cbc:EndpointID without the attribute is left to BR-62 and BR-63.

The attribute must equal a listed code exactly. Nothing is trimmed and case is not folded: when tried, schemeID=" 0088 " failed this rule while the EN 16931 layer passed.

The Peppol list is narrower than the EAS list pinned for BR-CL-25. Codes such as 0037, 0147 and 0212, and the letter codes AN, AQ, AS, AU and EM, are on the EAS list and not on the Peppol one. When tried, schemeID="0037" passed the EN 16931 layer and failed this rule alone.

The identifier value is not read here. Format checks for particular schemes are separate rules, such as PEPPOL-COMMON-R040 for the GLN check digit under 0088.

How an integration ends up here

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

• The mapping writes a scheme name, such as GLN, where the numeric code is expected.
• A code taken from the EAS list is valid for EN 16931 but not among the schemes Peppol accepts.
• A fixed-width export pads the attribute with spaces.
• The code was stored as a number and lost its leading zeros, giving 88.
• The ISO 6523 code of a party identifier was copied to the electronic address, and not every such code is an electronic address scheme.

How to fix it

1. Use the finding location to see whether the seller or the buyer cbc:EndpointID is affected.
2. Take the scheme from the Peppol registration of that participant. A Peppol participant identifier is a scheme code and an identifier together, and schemeID must be that scheme code.
3. Write the code exactly as listed, four digits with leading zeros for the numeric codes, and no spaces.
4. Correct the scheme in the stored party data rather than only in the XML, so the EN 16931 and the Peppol checks see the same value.

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 seller electronic address is marked GLN

<cac:AccountingSupplierParty>
  <cac:Party>
    <cbc:EndpointID schemeID="GLN">7300010000001</cbc:EndpointID>
    <!-- postal address, tax scheme and legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingSupplierParty>

Fragment of the corrected invoice: the seller electronic address uses scheme 0088

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

Only the scheme of the seller cbc:EndpointID differs: GLN in the failing invoice, 0088 in the corrected one, with the identifier 7300010000001 unchanged. The failing document also reports BR-CL-25 on the EN 16931 layer, the EAS list check on the same attribute, because GLN is on neither list. One correction clears both findings.

Where it applies

• Invoice or credit note makes no difference. When tried, a credit note with GLN as the seller scheme reported the same pair of findings, and so did an invoice with GLN on the buyer address.
• A Peppol BIS Billing 3.0 rule, reported on the Peppol layer. The code list is the one in the pinned May 2026 release.
• A listed scheme shows the address is expressed in a form Peppol recognises. The validator does not look the participant up, so it cannot confirm that the address is registered or reachable.

Related rules

• BR-CL-25 checks the same attribute against the wider EAS list on the EN 16931 layer
• BR-62 reports a seller EndpointID that has no schemeID attribute to check
• PEPPOL-COMMON-R040 checks the identifier itself when the scheme is 0088
• PEPPOL-EN16931-R020 requires the seller EndpointID in the first place
• 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-EN16931-CL008 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.