# BR-08: Add the seller postal address

The seller `cac:Party` must contain a `cac:PostalAddress`. This rule checks only that the group is there; the country code inside it is checked by `BR-09`.

- 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-08/
- Explanation last updated: 2026-09-24

## The short answer

`BR-08` fails when `cac:AccountingSupplierParty/cac:Party` has no `cac:PostalAddress` child. Add the address of the selling entity there: at least `cac:Country/cbc:IdentificationCode`, and the street, city and postcode that the seller record holds.

The finding points at the document root, not at the seller party, since the check is made once for the whole document. An address written anywhere other than that one element, such as a registered address under `cac:PartyLegalEntity`, leaves the rule failing.

## What the rule checks

The rule asks one question: is there a `cac:PostalAddress` directly inside `cac:AccountingSupplierParty/cac:Party`? What the address contains is not examined here.

An empty `<cac:PostalAddress/>` is enough to satisfy it. When tried, that empty element was reported instead by `BR-09`, which wants a seller country code inside the address, and by `PEPPOL-EN16931-R008`, which rejects empty elements. An address holding nothing but the country code passed every layer.

No other address stands in for this one. When tried, an address in `cac:PartyLegalEntity/cac:RegistrationAddress` left `BR-08` failing and added the warning `UBL-CR-185`, which reports that element as outside the model. The buyer, tax representative and deliver-to addresses are separate groups with their own rules.

| Term | Meaning | UBL element |
|---|---|---|
| BG-5 | Seller postal address | `cac:AccountingSupplierParty/cac:Party/cac:PostalAddress` |
| BT-40 | Seller country code | `cac:AccountingSupplierParty/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:

- The seller address lives in company settings that the export does not read, and the seller party is built from the name and identifiers only.
- The address block is written only when a street line is present, so a seller record with a city and country but no street produces no `cac:PostalAddress` at all.
- The mapping sends the address to `cac:PartyLegalEntity/cac:RegistrationAddress` because it is the registered office, and nothing to `cac:PostalAddress`.
- The invoice is issued for a subsidiary or branch whose address was never configured, and the builder leaves the block out instead of stopping.

## How to fix it

1. Take the address of the selling entity from its master data: the entity named in `cac:PartyLegalEntity/cbc:RegistrationName`, not a warehouse or remittance address.
2. Write it as `cac:PostalAddress` inside `cac:AccountingSupplierParty/cac:Party`, after `cbc:EndpointID`, `cac:PartyIdentification` and `cac:PartyName` and before `cac:PartyTaxScheme`.
3. Include `cac:Country/cbc:IdentificationCode` as the last child of the address, with the ISO 3166-1 alpha-2 code such as `GB`. `BR-09` requires it and `BR-CL-14` checks the value.
4. Send the street, city and postcode as well. The validator accepts an address with only a country, but that is the minimum the rules test, not a complete address.
5. If the seller record has no address, stop the export and complete the record. Do not copy the buyer address or a placeholder into the seller party.

## 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 seller party goes from its electronic address straight to its tax scheme

```xml
<cac:AccountingSupplierParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
    <cac:PartyTaxScheme>
      <cbc:CompanyID>GB123456789</cbc:CompanyID>
      <!-- tax scheme omitted from this fragment -->
    </cac:PartyTaxScheme>
    <!-- legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingSupplierParty>
```

Fragment of the corrected invoice: the seller postal address sits between the electronic address and the tax scheme

```xml
<cac:AccountingSupplierParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
    <cac:PostalAddress>
      <cbc:StreetName>1 Example Street</cbc:StreetName>
      <cbc:CityName>London</cbc:CityName>
      <cbc:PostalZone>SW1A 1AA</cbc:PostalZone>
      <cac:Country>
        <cbc:IdentificationCode>GB</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
    <cac:PartyTaxScheme>
      <cbc:CompanyID>GB123456789</cbc:CompanyID>
      <!-- tax scheme omitted from this fragment -->
    </cac:PartyTaxScheme>
    <!-- legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingSupplierParty>
```

The corrected invoice has a seller `cac:PostalAddress` with street, city, postcode and country `GB`; the failing invoice has no seller address and is otherwise identical. `BR-08` is the only finding on the failing document. The seller country rule `BR-09` stays silent, because it runs inside the address and there is no address for it to run in.

### What the validator reported

- The failing invoice reports **BR-08**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/BR-08-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

- A `CreditNote` carries the seller address in the same place. When tried, a credit note without it reported `BR-08` alone, located at the `CreditNote` root.
- The requirement comes from EN 16931 and is reported on that layer; nothing on the Peppol layer objected to the missing seller address in the recorded example.
- An address in the wrong position among the children of `cac:Party` fails the XSD layer before this rule is reached: when tried, the seller address placed after `cac:PartyLegalEntity` gave an XSD failure, and the EN 16931 and Peppol layers were skipped.
- When both party addresses are missing, `BR-08` and `BR-10` are reported side by side, both at the root.

## Related rules

- [BR-10 is the same presence check for the buyer postal address](https://ironfang.uk/docs/finance/rules/BR-10.md)
- [BR-CL-14 checks that the country code in the address is a valid ISO 3166-1 code](https://ironfang.uk/docs/finance/rules/BR-CL-14.md)
- [BR-06 requires the seller legal name in the same party](https://ironfang.uk/docs/finance/rules/BR-06.md)
- [PEPPOL-EN16931-R008 reports a seller address element that is present but empty](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R008.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-08](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-08/) 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-08)
- [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