BR-CL-15: Use an ISO 3166-1 country code for the item country of origin

The short answer

BR-CL-15 fails when cac:Item/cac:OriginCountry/cbc:IdentificationCode is not a code on the ISO 3166-1 alpha-2 list. The recorded item gave its origin as EU; the element needs the code of one country, DE in the corrected invoice.

The European Union is not a country on that list. If the goods were produced in one member state, give that state; if the origin is unknown or spread over several countries, leave cac:OriginCountry out of the item.

What the rule checks

Every item country of origin is checked, one per line, and the finding names the line: cac:InvoiceLine[1]/cac:Item[1]/cac:OriginCountry[1]/cbc:IdentificationCode[1] in the recorded example.

Spaces around the code are ignored and the rest must match in upper case. When tried, DE passed, while de and the three-letter DEU failed.

The accepted list is the one BR-CL-14 applies to addresses, with XI and 1A besides the ISO codes. XI passed as an origin when tried.

Address countries are outside this rule. They belong to BR-CL-14, so a bad code in an address never reports BR-CL-15.

How an integration ends up here

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

• Product master data holds the origin as EU, the way it may appear on packaging, instead of the country of manufacture.
• Origins are stored as ISO alpha-3 codes such as DEU, or as country names.
• The value is typed by hand in lower case.
• A label abbreviation such as UK is copied; the ISO code for the United Kingdom is GB.

How to fix it

1. Find the line from the finding location, and the product it describes.
2. Look up the country where the goods were produced and write its ISO 3166-1 alpha-2 code in upper case.
3. Where only a region such as the EU is known, omit cac:OriginCountry for that item rather than sending a region code.
4. Convert alpha-3 codes and names where product data enters your system, with the same mapping you use for address countries.

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 item country of origin is EU

<cac:Item>
  <cbc:Name>Example service</cbc:Name>
  <cac:OriginCountry>
    <cbc:IdentificationCode>EU</cbc:IdentificationCode>
  </cac:OriginCountry>
  <!-- tax category omitted from this fragment -->
</cac:Item>

Fragment of the corrected invoice: the item country of origin is DE

<cac:Item>
  <cbc:Name>Example service</cbc:Name>
  <cac:OriginCountry>
    <cbc:IdentificationCode>DE</cbc:IdentificationCode>
  </cac:OriginCountry>
  <!-- tax category omitted from this fragment -->
</cac:Item>

Only the origin code differs: EU in the failing invoice, DE in the corrected one. The failing document reports BR-CL-15 alone, and the Peppol layer passed.

Where it applies

• Applies to Invoice and CreditNote; EU as the origin on a credit note line reported this rule alone when tried.
• Reported on the EN 16931 layer only: in every case tried, the Peppol layer passed, whatever the origin code.
• cac:OriginCountry may also hold a cbc:Name, which the EN 16931 layer discourages with the warning UBL-CR-591. Only the code is read by this rule.

Related rules

• BR-CL-14 applies the same country list to the addresses in the document
• BR-CL-13 checks another optional item code, the scheme of an item classification
• BR-CL-21 checks the scheme of a standard item identifier on the same item
• 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-CL-15 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.