BR-63:Buyer electronic address must have a scheme identifier
Fix: Add a valid EAS schemeID attribute to the Buyer cbc:EndpointID element. Invoice Navigator infers the code from the buyer's country and identifier type and inserts it automatically. Upload your invoice to fix this automatically.
Peppol BIS Billing 3.0 requires the Buyer electronic address (BT-49) — the cbc:EndpointID on cac:AccountingCustomerParty — to carry a schemeID attribute. Without it, the receiver Access Point cannot resolve the buyer participant and the invoice is rejected on ingress.
Engine Classification
deterministic_lookup
Confidence: 90% · Applied automatically in pipeline
What is BR-63?
BR-63 is a fatal validation rule defined in the EN 16931 specification. It validates the @schemeID must be present and non-empty. Value must come from the Peppol Electronic Address Scheme (EAS) code list. A missing or blank schemeID triggers BR-63. element under Party > EndpointID in the UBL invoice XML.
When this rule fires, the invoice is rejected by Peppol access points and never reaches the buyer.
Target path: Schematron assertion: cac:AccountingCustomerParty/cac:Party/cbc:EndpointID/@schemeID must be present and non-empty. Value must come from the Peppol Electronic Address Scheme (EAS) code list. A missing or blank schemeID triggers BR-63.
Why This Error Matters
BR-63 is one of the top two Peppol structural failures for ERP vendors migrating to BIS Billing 3.0. Without a schemeID the SMP lookup cannot resolve the buyer, so no Access Point in the four-corner model accepts the invoice.
BR-63 is a hard failure — the invoice must be corrected and re-sent before it can reach the recipient.
Invoice is rejected by the receiving Access Point. No routing, no delivery, no payment cycle until the invoice is corrected and re-sent.
Invoice Navigator can automatically correct this error in your pipeline. The fix is applied with full audit evidence, so your compliance trail remains intact.
Validator Behavior
- ·Causes invoice rejection
- ·Error returned: BR-63
- ·Specification: EN 16931
How to Fix It
Before / After
<cac:AccountingCustomerParty>
<cac:Party>
<cbc:EndpointID>DE123456789</cbc:EndpointID>
</cac:Party>
</cac:AccountingCustomerParty><cac:AccountingCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID="9930">DE123456789</cbc:EndpointID>
</cac:Party>
</cac:AccountingCustomerParty>Technical Reference
Schematron assertion: cac:AccountingCustomerParty/cac:Party/cbc:EndpointID/@schemeID must be present and non-empty. Value must come from the Peppol Electronic Address Scheme (EAS) code list. A missing or blank schemeID triggers BR-63.Code Example
<cbc:EndpointID schemeID="9930">DE123456789</cbc:EndpointID>Common Causes
- ·Buyer master data missing a Peppol EAS field
- ·ERP export writes EndpointID text but not the schemeID attribute
- ·Copy-paste from a partner list that only stored the identifier value
- ·Legacy UBL templates that predate Peppol BIS 3
- ·Manual XML authoring that omitted the attribute
Seeing this in production? The API handles BR-63 automatically. See the fix response →
ERP-Specific Causes
Commonly Seen In
Frequently Asked Questions
The buyer's EndpointID element (BT-49) is missing its schemeID attribute or the attribute value is empty.
Use the code that matches the buyer's registered identifier type: 0088 GLN, 0106 Dutch KvK, 0184 Danish CVR, 0192 Norwegian ORG, 0208 Belgian CBE, 9930 German VAT, and so on.
Yes when the buyer's country is known. Invoice Navigator applies the correct EAS code deterministically with 0.90 confidence. If country cannot be inferred, the fixer asks for it.
BR-62 checks the seller endpoint (BT-34). BR-63 checks the buyer endpoint (BT-49). Both must carry a schemeID; failures often occur together.
The default Electronic Reporting configuration for Peppol Sales Invoice does not populate schemeID for buyer records unless the customer master has the Peppol EAS lookup enabled.
Related Errors
Related Content
Last updated: 5 August 2026
Validate your invoice
Drop your XML here to check for BR-63
Auto-fix BR-63 in seconds
Upload your invoice and we fix this error automatically. Financial fields are never touched.