# BR-CL-14: Use an ISO 3166-1 alpha-2 country code in addresses

Every `cac:Country/cbc:IdentificationCode` must be a two-letter ISO 3166-1 code in upper case. The code for the United Kingdom is `GB`, not `UK`.

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

## The short answer

`BR-CL-14` fails when a `cac:Country/cbc:IdentificationCode` holds anything other than a code from the ISO 3166-1 alpha-2 list. In the recorded example the seller country is `UK`; the code for the United Kingdom is `GB`.

Every address country in the document is covered, whichever party it belongs to. The finding location gives the exact element to correct.

## What the rule checks

It runs on each `cbc:IdentificationCode` inside a `cac:Country`: the seller, buyer and tax representative postal addresses and the deliver-to address. When tried, `UK` in the buyer, tax representative and deliver-to addresses was reported at each of those elements.

Surrounding spaces are removed and what is left must match a listed code exactly, in upper case. When tried, `gb`, `GBR` and `United Kingdom` all failed.

The list follows ISO 3166-1 alpha-2 and also accepts `1A` and `XI`; `XI`, used for Northern Ireland, passed as a buyer country when tried. `EL`, the prefix Greece uses on VAT numbers, is not on the list, and as a buyer country it failed.

An empty code fails as well. When tried, an empty buyer code reported this rule together with `BR-11` and `PEPPOL-EN16931-R008`.

The country of origin of an item is out of scope: when tried, `UK` in `cac:Item/cac:OriginCountry` was reported by `BR-CL-15` instead.

| Term | Meaning | UBL element |
|---|---|---|
| BT-40 | Seller country code | `cac:AccountingSupplierParty/cac:Party/cac:PostalAddress/cac:Country/cbc:IdentificationCode` |
| BT-55 | Buyer country code | `cac:AccountingCustomerParty/cac:Party/cac:PostalAddress/cac:Country/cbc:IdentificationCode` |
| BT-69 | Tax representative country code | `cac:TaxRepresentativeParty/cac:PostalAddress/cac:Country/cbc:IdentificationCode` |
| BT-80 | Deliver to country code | `cac:Delivery/cac:DeliveryLocation/cac:Address/cac:Country/cbc:IdentificationCode` |

## How an integration ends up here

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

- The country is stored as `UK`, the familiar abbreviation, which is not the ISO code for the United Kingdom.
- Country codes come from a system that uses ISO alpha-3 codes such as `GBR`, or numeric codes.
- The address holds a country name, and the mapping writes the name into `cbc:IdentificationCode`.
- Codes are typed by hand in lower case and sent as typed.
- The VAT prefix of the party, such as `EL` for Greece, is reused as its address country.

## How to fix it

1. Find the element from the finding location; it names the party and the address.
2. Convert the stored value to its ISO 3166-1 alpha-2 code in upper case: `GB` for the United Kingdom, `GR` for Greece, `DE` for Germany.
3. Do the conversion where addresses are stored, or in one shared mapping, so that every party and the deliver-to address are treated alike.
4. Keep the VAT identifier prefix separate from the address country. For Greece the two differ: the VAT number begins `EL` and the country code is `GR`.

## 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 gives its country as UK

```xml
<cac:AccountingSupplierParty>
  <cac:Party>
    <!-- endpoint omitted from this fragment -->
    <cac:PostalAddress>
      <cbc:StreetName>1 Example Street</cbc:StreetName>
      <cbc:CityName>London</cbc:CityName>
      <cbc:PostalZone>SW1A 1AA</cbc:PostalZone>
      <cac:Country>
        <cbc:IdentificationCode>UK</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
    <!-- tax scheme and legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingSupplierParty>
```

Fragment of the corrected invoice: the seller country is GB

```xml
<cac:AccountingSupplierParty>
  <cac:Party>
    <!-- endpoint omitted from this fragment -->
    <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>
```

Only the seller country code differs: `UK` in the failing invoice, `GB` in the corrected one. The failing document reports `BR-CL-14` alone. The seller country rule `BR-09` is satisfied, because it asks only for a value and `UK` is one.

### What the validator reported

- The failing invoice reports **BR-CL-14**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/BR-CL-14-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 credit note gets the same treatment: when tried, `UK` as its seller country reported this rule alone.
- Reported on the EN 16931 layer; the Peppol layer passed in the recorded example.
- Country codes are not compared with anything else. The rule does not check that a seller whose VAT number begins `GB` has a `GB` address.

## Related rules

- [BR-11 requires a country code in the buyer address, which this rule then checks](https://ironfang.uk/docs/finance/rules/BR-11.md)
- [BR-57 requires a country code element in the deliver-to address](https://ironfang.uk/docs/finance/rules/BR-57.md)
- [BR-CO-09 checks VAT number prefixes against a similar list that also accepts EL](https://ironfang.uk/docs/finance/rules/BR-CO-09.md)
- [BR-08 requires the seller postal address that holds the country code](https://ironfang.uk/docs/finance/rules/BR-08.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-CL-14](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-CL-14/) 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-CL-14)
- [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