Skip to content

BR-10: Add the buyer postal address

The buyer cac:Party needs a cac:PostalAddress child. Only its presence is tested here; the buyer country code inside it is the subject of BR-11.

EN 16931Fatal: the document is invalidParties and addresses

The short answer

BR-10 fails when there is no cac:PostalAddress inside cac:AccountingCustomerParty/cac:Party. Add the postal address of the customer you are invoicing there, including cac:Country/cbc:IdentificationCode.

A delivery address does not satisfy it. The ship-to address belongs under cac:Delivery, and the rule reads only the buyer party.

What the rule checks

This is a presence check on a single element: cac:PostalAddress as a direct child of the buyer cac:Party. The rule does not read the content of the address.

An address group with no children passes BR-10. When tried, <cac:PostalAddress/> in the buyer party was reported instead by BR-11, for the missing country code, and by PEPPOL-EN16931-R008, for the empty element.

The smallest buyer address that passes all layers is one holding only the country code: when tried, a buyer cac:PostalAddress containing just cac:Country/cbc:IdentificationCode produced no findings.

The rule is evaluated against the document as a whole, so the finding location is the root element rather than the buyer party.

TermMeaningUBL element
BG-8Buyer postal addresscac:AccountingCustomerParty/cac:Party/cac:PostalAddress
BT-55Buyer country codecac:AccountingCustomerParty/cac:Party/cac:PostalAddress/cac:Country/cbc:IdentificationCode

How an integration ends up here

Possible causes, from the shape of the rule rather than from measured usage:

  • Customers set up for electronic invoicing were created with a name and an electronic address only, and the address fields were never filled.
  • The only address on the order is the ship-to, and the mapping writes it to cac:Delivery and leaves the buyer party without one.
  • The builder skips the address block whenever the street is blank, even when a city and country are known.
  • Buyer details come from a customer reference on the order that carries identifiers but not the address.

How to fix it

  1. Read the postal address of the buyer from the customer master record: the party being invoiced, not the delivery point.
  2. Emit it as cac:PostalAddress inside cac:AccountingCustomerParty/cac:Party, after cac:PartyName if present and before cac:PartyTaxScheme and cac:PartyLegalEntity.
  3. End the address with cac:Country/cbc:IdentificationCode holding the two-letter ISO 3166-1 code; without it the next finding is BR-11.
  4. Where the customer record has no address, complete the record. Copying the seller or delivery address into the buyer party states something untrue about the buyer.

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 party has an electronic address and a legal entity but no postal address

<cac:AccountingCustomerParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
    <cac:PartyLegalEntity>
      <cbc:RegistrationName>Example Buyer Ltd</cbc:RegistrationName>
      <cbc:CompanyID>87654321</cbc:CompanyID>
    </cac:PartyLegalEntity>
  </cac:Party>
</cac:AccountingCustomerParty>

Fragment of the corrected invoice: the buyer postal address comes before the legal entity

<cac:AccountingCustomerParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
    <cac:PostalAddress>
      <cbc:StreetName>2 Example Street</cbc:StreetName>
      <cbc:CityName>London</cbc:CityName>
      <cbc:PostalZone>SW1A 2AA</cbc:PostalZone>
      <cac:Country>
        <cbc:IdentificationCode>GB</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
    <cac:PartyLegalEntity>
      <cbc:RegistrationName>Example Buyer Ltd</cbc:RegistrationName>
      <cbc:CompanyID>87654321</cbc:CompanyID>
    </cac:PartyLegalEntity>
  </cac:Party>
</cac:AccountingCustomerParty>

The only difference is the buyer cac:PostalAddress, with street, city, postcode and country GB, between the buyer cbc:EndpointID and cac:PartyLegalEntity. The failing document reports BR-10 and nothing else. BR-11 does not appear, because its check runs inside the buyer address and the failing document has none.

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

  • Credit notes need the buyer address in the same place. When tried, removing it from a credit note reported BR-10 at the CreditNote root.
  • This is an EN 16931 finding. The recorded failing invoice has a clean Peppol layer, so the buyer address requirement reaches you from EN 16931 alone.
  • A document missing both the seller and the buyer address reports BR-08 and BR-10 together.
  • An address placed after cac:PartyLegalEntity breaks the UBL element order and is rejected at the XSD layer, so this rule is not reached.

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-24.1: source checked 2026-09-24, explanation last updated 2026-09-24.

The official definition of BR-10 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.