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

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.

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.

Validate your corrected invoice

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

<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

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

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
• BR-11 asks the same of the buyer postal address
• BR-CL-14 checks the code against the ISO 3166-1 country list once it is there
• BR-20 requires a country code in the tax representative address too
• Browse every rule in the reference
• Background: Understanding EN 16931 validation errors

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