PEPPOL-EN16931-CL008: Invalid Electronic Address Scheme, the Peppol Rule Explained

What PEPPOL-EN16931-CL008 checks

CL008 is a code list rule: the scheme of an electronic address, the schemeID attribute on cbc:EndpointID for the seller (BT-34-1) and buyer (BT-49-1), must be a code from the Peppol Electronic Address Scheme (EAS) list. The scheme tells the network what kind of identifier the value is, and only identifier types the Peppol infrastructure can resolve are allowed. Everything else, including the core-legal EM for email, is rejected.

Layer and formats

Findings carry "layer": "cius": the restriction is part of the Peppol overlay on top of the European core, applied when validating against the Peppol BIS profile. Under options.profile en16931 the overlay is dropped and the broader core code list applies, so legacy codes like EM pass there, exactly as the finding's message says.

Why it fails in practice

Email-era data. Systems that exchanged invoices by email stored EM plus an address; pointed at Peppol, every document fails CL008.
The scheme is guessed. A developer fills the attribute with a country code, "VAT", or the identifier type name instead of the numeric EAS code.
Right identifier, wrong list. ISO 6523 ICDs and EAS codes overlap but are not identical; a code copied from an ICD table may not be in the EAS list.

How to fix it

Use the numeric EAS code matching the identifier type the party is registered under:

<cbc:EndpointID schemeID="9930">DE123456789</cbc:EndpointID>
<!-- or 0204 for a Leitweg-ID, 0088 for a GLN -->

In an InvoiceXML create request the value is the schemeId of seller.electronicAddress and buyer.electronicAddress. Requests carrying a non-EAS scheme on the Peppol profile are rejected up front with a model error naming the field, before any XML is built.

The raw rejection vs the InvoiceXML finding

The raw Schematron text names a code list and stops there:

<svrl:failed-assert id="PEPPOL-EN16931-CL008" flag="fatal"
    location="/*:Invoice[namespace-uri()='...']/cac:AccountingSupplierParty[1]/cac:Party[1]/cbc:EndpointID[1]/@schemeID">
  <svrl:text>Electronic address identifier scheme must be from
    the codelist "Electronic Address Identifier Scheme"</svrl:text>
</svrl:failed-assert>

The InvoiceXML finding explains the situation and the way out:

{
  "rule": "PEPPOL-EN16931-CL008",
  "layer": "cius",
  "line": null,
  "message": "The electronic address scheme is not a valid Peppol Electronic Address Scheme (EAS) code. Legacy codes such as \"EM\" are only accepted under the en16931 profile; for Peppol use a numeric code, e.g. 9930 (German VAT), 0204 (Leitweg-ID) or 0088 (GLN).",
  "btCodes": ["BT-34", "BT-49"],
  "fields": ["seller.electronicAddress.identifier", "buyer.electronicAddress.identifier"],
  "raw": "[PEPPOL-EN16931-CL008] CIUS: Electronic address identifier scheme must be from the codelist \"Electronic Address Identifier Scheme\""
}

Your end customer reads a message that names concrete valid codes instead of a code list title, and your UI knows which inputs to mark. The message table is keyed by rule code, so clients can localize by rule and keep the mapping.

Check or generate Peppol documents

Validate a document in the UBL validator to see every address finding with its field path, or generate with POST /v1/create/ubl, where scheme codes are checked against the current EAS list server-side, updated with each Peppol release. The Peppol hub has the broader routing story.

PEPPOL-EN16931-R020 and PEPPOL-EN16931-R010, when the addresses are missing entirely
PEPPOL-EN16931-R001, the business process declaration
The Peppol BIS Billing 3.0 CustomizationID, the identifier that switches the overlay on

Frequently asked questions

Why is schemeID="EM" rejected on Peppol?

The core EN 16931 code list for electronic addresses includes alphanumeric codes like EM (email). Peppol restricts the list to the numeric EAS codes that map to registrable participant identifiers, because routing needs an identifier type the SML/SMP infrastructure can resolve. An email address is not a Peppol endpoint.

Which EAS codes are the common ones?

9930 for a German VAT number, 0204 for a German Leitweg-ID, 0088 for a GLN, 0192 for a Norwegian organisation number, 0208 for a Belgian enterprise number. The full list is the Peppol EAS code list; pick the code matching the identifier type your party is registered under.

Does the code have to match the identifier value?

Semantically yes: 9930 announces that the value is a German VAT number, so putting a GLN behind it will route wrong or nowhere even if validation passes. CL008 checks list membership; correctness of the pairing is your data quality job.

The finding hits BT-34 and BT-49 at once. Why?

The rule checks every electronic address element in the document, seller and buyer alike. If both carry an invalid scheme, you get one finding per occurrence; the InvoiceXML finding lists both field paths so each input can be highlighted.

PEPPOL-EN16931-CL008