# 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`.

- Layer: EN 16931
- Severity: fatal (the document is invalid)
- Topics: Parties and addresses
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-10/
- Explanation last updated: 2026-09-24

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

| Term | Meaning | UBL element |
|---|---|---|
| BG-8 | Buyer postal address | `cac:AccountingCustomerParty/cac:Party/cac:PostalAddress` |
| BT-55 | Buyer country code | `cac: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.

## 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

```xml
<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

```xml
<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

- The failing invoice reports **BR-10**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/BR-10-invalid.xml)
  - [Download the corrected XML](https://ironfang.uk/finance/rule-examples/invoice-minimal.xml)

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.

## Related rules

- [BR-11 requires the country code inside the buyer address once the address exists](https://ironfang.uk/docs/finance/rules/BR-11.md)
- [BR-08 is the same presence check for the seller postal address](https://ironfang.uk/docs/finance/rules/BR-08.md)
- [BR-07 requires the buyer legal name in the same party](https://ironfang.uk/docs/finance/rules/BR-07.md)
- [BR-CL-14 checks that the buyer country code is a valid ISO 3166-1 code](https://ironfang.uk/docs/finance/rules/BR-CL-14.md)

## 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](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/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.

## Links

- [This rule as a web page](https://ironfang.uk/docs/finance/rules/BR-10)
- [Free Peppol invoice validator](https://ironfang.uk/tools/peppol-validator)
- [Rule index](https://ironfang.uk/docs/finance/rules.md)
- [Ironfang Finance API docs](https://ironfang.uk/docs/finance)
- The same rule is available to MCP clients as the tool `finance.rule.get` on https://mcp.ironfang.uk/mcp