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 tocac:Country/cbc:Nameor 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
- Hold a country code on every customer address, converting names to ISO 3166-1 alpha-2 codes where the source stores names.
- Write it as
cac:Country/cbc:IdentificationCodeinside the buyercac:PostalAddress, after the street, city, postcode and subdivision elements. - 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
- The failing invoice reports BR-11. The corrected document passes every layer with no findings.Download the failing XMLDownload the corrected 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
CreditNotebuyer address is checked the same way. When tried, the credit note version reportedBR-11at the buyercac: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 hasBR-57, which is weaker: it tests only that the code element exists, so an empty deliver-to code passes it. BR-11belongs to the EN 16931 layer. Peppol adds a finding of its own only when an emptycac:Countryor 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
- BR-CL-14 checks that the country code is on the ISO 3166-1 list
- BR-57 requires a country code element in the deliver-to address, without checking that it has a value
- PEPPOL-EN16931-R008 is reported as well when the country element is present but empty
- 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-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.
