# BR-11: Add the country code to the buyer postal address

A buyer `cac:PostalAddress` must contain `cac:Country/cbc:IdentificationCode` with a value. A missing, empty or blank code fails alike.

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

## The short answer

`BR-11` fails when the buyer `cac:PostalAddress` has no `cac:Country/cbc:IdentificationCode`, or has one with no visible text. Add the two-letter ISO 3166-1 code of the country the buyer address is in, such as `GB`, as `cac:Country/cbc:IdentificationCode` at the end of that address.

A country name does not count. `cac:Country/cbc:Name` is outside the invoice model: when tried, it left `BR-11` failing and added the warning `UBL-CR-229`.

## What the rule checks

The rule runs once for each buyer `cac:PostalAddress`, and the finding is located at that address. It takes the text of `cac:Country/cbc:IdentificationCode`, strips surrounding whitespace, and fails if nothing is left.

Absent and blank are treated the same. When tried, a missing `cac:Country`, an empty `<cac:Country/>`, an empty code and a code of two spaces all reported `BR-11`. Each empty variant also brought `PEPPOL-EN16931-R008`, and the empty or blank code brought `BR-CL-14` too, since an empty value is not on the country list.

Whether the value is a genuine country code is left to another rule: `UK` has text, so it passes `BR-11` and is then rejected by `BR-CL-14`.

The rule needs an address to run in. If the buyer party has no `cac:PostalAddress`, `BR-10` reports that and `BR-11` is silent.

| Term | Meaning | UBL element |
|---|---|---|
| BT-55 | Buyer country code | `cac:AccountingCustomerParty/cac:Party/cac:PostalAddress/cac:Country/cbc:IdentificationCode` |
| BG-8 | Buyer postal address | `cac:AccountingCustomerParty/cac:Party/cac:PostalAddress` |

## How an integration ends up here

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

- The customer record stores the country as a name, such as `United Kingdom`, and the mapping writes it to `cac:Country/cbc:Name` or drops it because it is not a code.
- Domestic customers have no country filled in because the system assumes the home country, and the export writes nothing for them.
- A lookup from country name to code returns nothing for an unexpected spelling, and the serialiser writes an empty element or none.
- The address is built from street, city and postcode fields, and the country was never added to the mapping.

## How to fix it

1. Hold a country code on every customer address, converting names to ISO 3166-1 alpha-2 codes where the source stores names.
2. Write it as `cac:Country/cbc:IdentificationCode` inside the buyer `cac:PostalAddress`, after the street, city, postcode and subdivision elements.
3. Do not fill a missing buyer country with the seller country by default. Resolve the gap in the customer record, where the real address is known.

## 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 address ends at the postcode, with no country

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

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

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

The corrected invoice adds `cac:Country` with `cbc:IdentificationCode` `GB` as the last child of the buyer address; the street, city and postcode are unchanged. `BR-11` is the only finding on the failing document. The seller address still has its country, so `BR-09`, the matching seller rule, has nothing to report.

### What the validator reported

- The failing invoice reports **BR-11**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/BR-11-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` buyer address is checked the same way. When tried, the credit note version reported `BR-11` at the buyer `cac:PostalAddress`.
- The seller has its own rule for the same field, `BR-09`, and so does the tax representative, `BR-20`. The deliver-to address has `BR-57`, which is weaker: it tests only that the code element exists, so an empty deliver-to code passes it.
- `BR-11` belongs to the EN 16931 layer. Peppol adds a finding of its own only when an empty `cac:Country` or code element is left behind; with the country missing altogether, as in the recorded example, it passes.

## Related rules

- [BR-10 reports a buyer party with no postal address at all, where this rule cannot run](https://ironfang.uk/docs/finance/rules/BR-10.md)
- [BR-CL-14 checks that the country code is on the ISO 3166-1 list](https://ironfang.uk/docs/finance/rules/BR-CL-14.md)
- [BR-57 requires a country code element in the deliver-to address, without checking that it has a value](https://ironfang.uk/docs/finance/rules/BR-57.md)
- [PEPPOL-EN16931-R008 is reported as well when the country element 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-11](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-11/) 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-11)
- [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