Attestwire › Rule reference › BR-63
BR-63 The buyer electronic address needs a scheme identifier
noun · EN 16931 · fatal · BT-49
an address with no postcode, in Peppol terms.
Your invoice was refused because the buyer’s electronic address is there, but it does not say what kind of identifier it is. The address is where the invoice gets delivered on Peppol, the network many European buyers receive invoices through, and the network needs both parts to find the buyer. This is a one-attribute fix once you have the right value from the buyer.
- Business term
BT-49— Buyer electronic address- Severity
fatal- Applies to
peppol-bis-3, xrechnung-ubl, xrechnung-cii
The fix
Set the scheme on the buyer’s electronic address to the code the buyer gave you. In this library that is electronicAddress.schemeId, for example 9930 for a German VAT identifier, 0204 for a Leitweg-ID (the routing code a German public body gives its suppliers) or 0088 for a GLN, and keep the value unchanged, as the buyer supplied it.
If you are not sure the identifier is registered, run the hosted recipient lookup before you send.
What the rule requires
The one idea: a Peppol identifier is a scheme and a value. The scheme says what kind of number the value is, for example a German VAT number or a global location number, and the network looks a participant up by both together. The same string can be a VAT number under one scheme and something else under another, so a bare value is ambiguous.
Every field in a European e-invoice has a number, and the buyer’s electronic address is field 49, written BT-49. BR-63 is the name of the rule that checks it has a scheme.
Ask the buyer for both parts rather than guessing the scheme from the shape of the value. Registration under one scheme does not prove registration under another, even when both values refer to the same organisation. In UBL, one of the two XML formats an e-invoice can be written in, the scheme is the schemeID attribute on cbc:EndpointID; in this library it is electronicAddress.schemeId beside electronicAddress.value. The Peppol identifier guide sets the look-alike fields side by side and explains what a lookup does and does not establish.
A passing value
"electronicAddress": { "schemeId": "9930", "value": "y" }Why it exists
A Peppol access point, the service provider that connects you to the network, does not deliver to a company name or a bare number. It resolves the participant by scheme and value, so an address with no scheme cannot be resolved at all. Reporting the missing scheme before sending is cheaper than a delivery failure after.
What the library returns
The full error returned by @attestwire/en16931. It includes the rule ID,
affected field and suggested correction. Developers can use this object in their application:
{
"rule": "BR-63",
"field": "BT-49",
"severity": "fatal",
"message": "The buyer electronic address (BT-49) must have a scheme identifier. The bare value \"y\" is ambiguous — the same string can be a VAT number under one scheme and a GLN under another, and the receiving access point resolves it by scheme.",
"fix": "Set electronicAddress.schemeId to the Peppol EAS code, e.g. \"9930\" for a German VAT identifier, \"0204\" for a Leitweg-ID, \"0088\" for a GLN.",
"example": "\"electronicAddress\": { \"schemeId\": \"9930\", \"value\": \"y\" }",
"xpath": "/ubl:Invoice/cac:AccountingCustomerParty/cac:Party/cbc:EndpointID/@schemeID",
"docsUrl": "https://attestwire.com/rules/BR-63"
}
xpath is always a UBL path. On a CII invoice, look for the
matching CII field instead.
How our check differs
Our check is presence-only. It reports a blank scheme and does not confirm that the code is on the current EAS list (the Peppol list of allowed schemes) or that the value is registered under it. A wrong but present scheme passes here and fails at delivery. The guide linked above explains the separate lookup.
See also: PEPPOL-EN16931-R010 — the rule that reports the address missing altogether; BR-62 — the same requirement for the seller electronic address.