Skip to content

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.

EN 16931Fatal: the document is invalidParties and addresses

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.

TermMeaningUBL element
BT-55Buyer country codecac:AccountingCustomerParty/cac:Party/cac:PostalAddress/cac:Country/cbc:IdentificationCode
BG-8Buyer postal addresscac: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.

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

<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

<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

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.

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