Skip to content

BR-63Add the schemeID attribute to the buyer electronic address

A buyer cbc:EndpointID must carry a schemeID attribute. The rule tests that the attribute exists, not what it contains.

EN 16931Fatal: the document is invalidParties and addresses

The short answer

BR-63 fails when the buyer electronic address, cac:AccountingCustomerParty/cac:Party/cbc:EndpointID, has no schemeID attribute. Add the attribute, set to the code of the scheme the buyer identifier belongs to.

Unlike the seller side, this value changes from one document to the next. One customer may be addressed by GLN and the next by a national organisation number, so the scheme has to be stored per customer, not configured once.

What the rule checks

The rule selects the buyer cbc:EndpointID and requires a schemeID attribute on it. With no buyer cbc:EndpointID in the document it does not report; that gap is PEPPOL-EN16931-R010.

Existence is all that is tested. An attribute that is present but empty, schemeID="", passes BR-63 and fails the code list rules instead: BR-CL-25, and PEPPOL-EN16931-CL008 on the Peppol layer.

A buyer cbc:EndpointID with neither content nor attribute reports BR-63 and, for the empty element, PEPPOL-EN16931-R008.

TermMeaningUBL element
BT-49Buyer electronic addresscac:AccountingCustomerParty/cac:Party/cbc:EndpointID
BT-49Buyer electronic address: its scheme identifier attributecac: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 customer record has a single electronic address field and nowhere to keep the scheme.
  • Customers were imported from a list that gave the identifiers only, so the scheme column is empty for those records.
  • The mapping hard-codes the scheme for customers in the home country and emits nothing for the rest.
  • The scheme is written to schemeName or another attribute. Only schemeID counts, and schemeName also draws the warning UBL-DT-08.

How to fix it

  1. Ask the buyer which identifier and scheme they receive documents under, and record both. Do not infer the scheme from the length or look of the identifier.
  2. Add a scheme field to the customer record if there is none, and make it mandatory whenever an electronic address is entered.
  3. Map the scheme to the schemeID attribute and the identifier to the content of cac:AccountingCustomerParty/cac:Party/cbc:EndpointID.
  4. Validate the stored code against the EAS code list when it is entered, so BR-CL-25 does not surface later at sending time.

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 EndpointID has no schemeID

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

Fragment of the corrected invoice: the buyer EndpointID states its scheme

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

The attribute schemeID="0088" on the buyer cbc:EndpointID is the whole difference; the identifier is unchanged. The failing document reports only BR-63, on the EN 16931 layer, and its Peppol layer passes. The seller cbc:EndpointID in the same file keeps its attribute, which is why BR-62 is not reported.

What the validator reported

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 Invoice and CreditNote. The same edit to a credit note reports the same single finding.
  • The rule covers the buyer party only. An cbc:EndpointID on the seller is BR-62.
  • It is part of EN 16931 and reports on that layer. Peppol adds the requirement that the element is present in the first place.

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