# BR-09: Give the seller postal address a country code

The seller `cac:PostalAddress` needs `cac:Country/cbc:IdentificationCode` holding an ISO 3166-1 code such as `GB`. A missing or blank code fails.

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

## The short answer

`BR-09` fails when the seller `cac:PostalAddress` has no `cac:Country/cbc:IdentificationCode`, or one that is blank. Write the two-letter ISO 3166-1 alpha-2 code of the country the seller address is in as the last child of that address: `GB` in the recorded example.

A country name is not a substitute. When tried, `cac:Country/cbc:Name` holding `United Kingdom` in place of the code left `BR-09` failing and added the warning `UBL-CR-166`, because the name is outside the invoice model.

## What the rule checks

The rule is evaluated inside each seller `cac:PostalAddress` and reports at that address. It trims the text of `cac:Country/cbc:IdentificationCode` and fails when nothing is left, whether the `cac:Country` group is missing or the code inside it is empty.

An empty or blank code brings two more findings with it. When tried, an empty `cbc:IdentificationCode` and one holding a single space each reported `BR-09`, `BR-CL-14` for a value that is not on the country list, and `PEPPOL-EN16931-R008` for the element with no content.

Whether the text is a real code is not examined here. When tried, `gb` in lower case passed `BR-09` and was rejected by `BR-CL-14`, which matches the ISO 3166-1 list exactly, capitals included.

The rule has nothing to run in when the seller has no address at all. That document reports `BR-08` instead, and `BR-09` stays silent.

| Term | Meaning | UBL element |
|---|---|---|
| BT-40 | Seller country code | `cac:AccountingSupplierParty/cac:Party/cac:PostalAddress/cac:Country/cbc:IdentificationCode` |
| BG-5 | Seller postal address | `cac:AccountingSupplierParty/cac:Party/cac:PostalAddress` |

## How an integration ends up here

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

- The company settings hold the seller country as a name, and the mapping writes it to `cac:Country/cbc:Name` or leaves it out because it is not a code.
- The home country is assumed rather than stored, so the seller record has no country field and the export writes no `cac:Country`.
- The seller and buyer addresses are built by separate code, and the country was only ever added to the buyer mapping.
- A lookup from a stored country name to a code fails on an unexpected spelling and returns an empty string, which is written as an empty element.

## How to fix it

1. Take the country from the seller master data: the country of the address sent in `cac:AccountingSupplierParty/cac:Party/cac:PostalAddress`.
2. Convert it to the upper-case ISO 3166-1 alpha-2 code, for example `GB`, `DE` or `NL`.
3. Write it as `cac:Country/cbc:IdentificationCode` at the end of the address, after `cbc:PostalZone` and after any `cbc:CountrySubentity` or `cac:AddressLine`.
4. Do not send `cac:Country/cbc:Name`. The code is the only country element the model uses, and the name draws a warning.
5. If the seller record has no country, stop the export and complete the record instead of writing an empty element.

## 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 address ends at the postcode

```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:PostalAddress>
    <!-- tax scheme and legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingSupplierParty>
```

Fragment of the corrected invoice: the seller address closes with country code GB

```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>
    <!-- tax scheme and legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingSupplierParty>
```

The corrected invoice ends the seller address with `cac:Country` holding `GB`; the failing invoice stops after the postcode and is otherwise identical. `BR-09` is the only finding on the failing document. The buyer address keeps its country, so `BR-11` stays silent, and with no code present there is nothing for `BR-CL-14` to check.

### What the validator reported

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

- Applies to `Invoice` and `CreditNote` alike. When tried, a credit note whose seller address had no country reported `BR-09` alone, at the seller `cac:PostalAddress`.
- An EN 16931 rule. The Peppol layer raised nothing about the missing seller country in the recorded example.
- The buyer address has the same requirement under its own identifier. When tried, removing both countries reported `BR-09` and `BR-11` side by side, each at its own address.
- A seller tax representative, when there is one, needs a country code in its own address as well, which `BR-20` checks.

## Related rules

- [BR-08 requires the seller postal address that this code belongs in](https://ironfang.com/docs/finance/rules/BR-08.md)
- [BR-11 asks the same of the buyer postal address](https://ironfang.com/docs/finance/rules/BR-11.md)
- [BR-CL-14 checks the code against the ISO 3166-1 country list once it is there](https://ironfang.com/docs/finance/rules/BR-CL-14.md)
- [BR-20 requires a country code in the tax representative address too](https://ironfang.com/docs/finance/rules/BR-20.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-28.1: source checked 2026-09-28, explanation last updated 2026-09-28.

[The official definition of BR-09](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-09/) 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.com/docs/finance/rules/BR-09)
- [Free Peppol invoice validator](https://ironfang.com/tools/peppol-validator)
- [Rule index](https://ironfang.com/docs/finance/rules.md)
- [Ironfang Finance API docs](https://ironfang.com/docs/finance)
- The same rule is available to MCP clients as the tool `finance.rule.get` on https://mcp.ironfang.com/mcp