Attestwire › Rule reference › PEPPOL-EN16931-R010

PEPPOL-EN16931-R010 A Peppol invoice needs the buyer electronic address

noun · Peppol BIS · fatal or warning, by profile · BT-49

an invoice with nowhere to go.

Your invoice has no electronic address for the buyer. That address is where the invoice gets delivered on Peppol, the network many European buyers receive invoices through, and a postal address or an email cannot stand in for it. On a Peppol invoice this is fatal and the invoice is refused. On an XRechnung invoice, Germany’s version of the European standard, it is reported as a warning. Either way it is one field, and the buyer has the value.

Business term

BT-49 — Buyer electronic address

Severity

fatal or warning, by profile

Applies to

peppol-bis-3 (fatal); xrechnung-ubl, xrechnung-cii (warning)

The fix

Ask the buyer for their Peppol identifier and its scheme, set buyer.electronicAddress to both, and check again. If you want to know whether that identifier is registered and accepts invoices before you send, the hosted recipient lookup answers that with a dated receipt. A passing invoice check does not.

What the rule requires

The one idea: every participant on the network has an identifier made of a scheme (what kind of number it is) and a value, and the network delivers to that pair. Every field in a European e-invoice has a number, and the buyer’s electronic address is field 49, written BT-49. PEPPOL-EN16931-R010 is the name of the rule that checks it is present.

Ask the buyer for their Peppol identifier and its scheme, and put both in the buyer’s electronic address. In this library that is buyer.electronicAddress with schemeId and value. In UBL, one of the two XML formats an e-invoice can be written in, it is cbc:EndpointID with its schemeID attribute under the buyer party.

The electronic address is not the buyer reference (BT-10) and not the buyer identifier (BT-46). They are different fields with different jobs, and a value copied from one into another will pass this rule and still not reach the buyer. The Peppol identifier guide sets the four fields side by side.

A passing value

"electronicAddress": { "schemeId": "9930", "value": "DE123456789" }

Why it exists

Peppol delivery is addressed by participant identifier, not by company name. The rule exists so that an invoice that can never be delivered is refused before it leaves your system rather than after an access point has tried. XRechnung requires the field through its own field rules rather than through a named BR-DE rule, which is why this library reports the Peppol rule there, as a warning, instead of inventing an identifier.

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": "PEPPOL-EN16931-R010",
  "field": "BT-49",
  "severity": "warning",
  "message": "The buyer electronic address (BT-49) must be provided. This is the routing identifier a Peppol access point uses to deliver the document — a postal address and an email are not substitutes, and without it the invoice cannot be addressed on the network.",
  "fix": "Set buyer.electronicAddress to the participant identifier and its scheme, e.g. scheme \"9930\" (German VAT ID) or \"0204\" (Leitweg-ID). The full list is the Peppol EAS code list (ISO 6523 ICD).",
  "example": "\"electronicAddress\": { \"schemeId\": \"9930\", \"value\": \"DE123456789\" }",
  "xpath": "/ubl:Invoice/cac:AccountingCustomerParty/cac:Party/cbc:EndpointID",
  "docsUrl": "https://attestwire.com/rules/PEPPOL-EN16931-R010"
}

xpath is always a UBL path. On a CII invoice, look for the matching CII field instead.

How our check differs

See also: BR-63 — the rule that reports an address with no scheme; PEPPOL-EN16931-R020 — the same requirement for the seller electronic address.