The short answer
BR-CL-25 fails when a cbc:EndpointID has a schemeID that is not in the EAS code list shipped with the validation artefacts. Replace it with the EAS code for the scheme the identifier was really issued under, for example 0088 for a GLN.
The message does not say which party is affected. Check the schemeID on both the seller and the buyer cbc:EndpointID.
What the rule checks
The rule runs on every cbc:EndpointID in the document that has a schemeID attribute. Under Peppol that means the seller and buyer addresses; an cbc:EndpointID on any other party would be tested as well. An element without the attribute is skipped here and reported by BR-62 or BR-63.
Leading and trailing white space is ignored, and what remains must be exactly one code from the list. The match is case-sensitive, so em fails where EM is a listed code. An empty attribute, schemeID="", fails.
Only the scheme code is tested. Whether the identifier fits the scheme is a separate matter: Peppol checks the value format for some schemes, and a 0088 identifier with a wrong check digit reports PEPPOL-COMMON-R040.
Peppol tests the same attribute against its own list in PEPPOL-EN16931-CL008, and that check is the stricter of the two. schemeID=" 0088 " passes BR-CL-25 and fails PEPPOL-EN16931-CL008; so does EM, which is on the EN 16931 list and not accepted by the Peppol rule in this release.
| Term | Meaning | UBL element |
|---|---|---|
| BT-34 | Seller electronic address: its scheme identifier attribute | cac:AccountingSupplierParty/cac:Party/cbc:EndpointID/@schemeID |
| BT-49 | Buyer electronic address: its scheme identifier attribute | cac:AccountingCustomerParty/cac:Party/cbc:EndpointID/@schemeID |
How an integration ends up here
Possible causes, from the shape of the rule rather than from measured usage:
- The mapping writes the name of the scheme, such as
GLN, where the four-character code is expected. - The code lost its leading zeros on the way through a numeric column or a spreadsheet, turning
0088into88. - An internal identifier type from the source system is passed through unchanged.
- The scheme column is empty and the serialiser still writes the attribute, producing
schemeID="". - The value comes from another code list. ISO 6523 ICD codes used for
cac:PartyIdentificationandcac:PartyLegalEntityoverlap with EAS only in part.
How to fix it
- Work out which party the finding belongs to by reading the
schemeIDon eachcbc:EndpointID. - Identify the scheme of the stored identifier and look up its EAS code. If the identifier has no EAS scheme it cannot serve as the electronic address; obtain one that does from the party concerned.
- Store the code as text, four characters with any leading zeros, and write it to
schemeIDwithout padding. - Do not swap in a listed code only because it passes. A code that does not describe the identifier produces an address that points nowhere, or at someone else.
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: XXXX is not an EAS code
<cac:AccountingSupplierParty>
<cac:Party>
<cbc:EndpointID schemeID="XXXX">7300010000001</cbc:EndpointID>
<!-- postal address, tax scheme and legal entity omitted from this fragment -->
</cac:Party>
</cac:AccountingSupplierParty>Fragment of the corrected invoice: 0088 is the EAS code for a GLN
<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 schemeID on the seller cbc:EndpointID differs: XXXX in the failing file, 0088 in the corrected one. The failing document also reports PEPPOL-EN16931-CL008, because Peppol checks the same attribute against its own list of electronic address schemes and XXXX is on neither. Correcting the code clears both findings.
What the validator reported
- The failing invoice reports BR-CL-25 and
PEPPOL-EN16931-CL008. The corrected document passes every layer with no findings.Download the failing XMLDownload the corrected 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
- Applies to UBL
InvoiceandCreditNote. A credit note with an unknown scheme on the buyer address reports the same pair of findings. - The list is the one pinned in the EN 16931 1.3.16 artefacts. EAS is revised from time to time, so a code added or withdrawn upstream takes effect here only with a new artefact release.
- A listed scheme and a well-formed identifier describe an address; they do not show that anyone is registered at it. The validator does not query the Peppol network, so reachability has to be confirmed separately.
Related rules
- BR-62 reports a seller EndpointID that has no schemeID attribute
- BR-63 reports a buyer EndpointID that has no schemeID attribute
- PEPPOL-EN16931-R020 requires the seller EndpointID to be present
- PEPPOL-EN16931-R010 requires the buyer EndpointID to be present
- Browse every rule in the reference
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-20.1: source checked 2026-09-20, explanation last updated 2026-09-20.
The official definition of BR-CL-25 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.