BR-CO-09Add the country prefix to a VAT identifier

The short answer

BR-CO-09 fails when a VAT identifier does not start with a recognised two-letter country prefix. Write the identifier in cac:PartyTaxScheme/cbc:CompanyID in its full form, prefix included: GB123456789, not 123456789.

The finding does not name the party. The rule covers the seller, the buyer and the seller tax representative, so check the cbc:CompanyID of every cac:PartyTaxScheme whose tax scheme is VAT.

What the rule checks

The rule runs on every cac:PartyTaxScheme in the document whose cac:TaxScheme/cbc:ID is VAT; the scheme ID is trimmed and upper-cased first, so vat is included. A seller cac:PartyTaxScheme with any other scheme ID, which is where a non-VAT tax registration goes, is not tested.

It takes the first two characters of cbc:CompanyID and looks for them in a fixed list: the ISO 3166-1 alpha-2 country codes, plus EL for Greece, XI for Northern Ireland and the code 1A. The comparison is case-sensitive, so gb123456789 fails. UK is not a listed code and fails too.

Greece appears twice. Greek VAT identifiers are issued with the prefix EL, while the ISO code for the country is GR; the list holds both and either passes.

Nothing after the prefix is examined. The rule does not check the length or check digits of the number, and it does not compare the prefix with the country in the postal address of the party: FR12345678901 on a seller with a GB address passes.

How an integration ends up here

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

• The source system keeps VAT numbers in domestic form, without the prefix, because every customer used to be in one country.
• The prefix is held in a separate country field and the mapping sends only the number.
• The prefix is there in lower case, or the identifier uses UK where the VAT prefix is GB.
• A value that is not a VAT identifier, such as a company registration number or a local tax reference, has been mapped into the VAT cac:PartyTaxScheme.
• Only the seller identifier was normalised, and the buyer or tax representative identifier arrives as typed by a user.

How to fix it

1. Find the party at fault by reading cbc:CompanyID in each cac:PartyTaxScheme with scheme VAT: under cac:AccountingSupplierParty, cac:AccountingCustomerParty and, if present, cac:TaxRepresentativeParty.
2. Emit the identifier exactly as the tax authority issued it, prefix first, in upper case and with no space or punctuation before the prefix.
3. Where the prefix is missing from the stored data, correct the stored identifier. Do not prepend the postal country code in the mapping as a blanket rule: the two can differ, Greece being the standing example with EL against GR.
4. If the value is not a VAT identifier, take it out of the VAT scheme. A party that has no VAT identifier should not be given one so that the rule passes; the VAT category rules decide when an identifier is required, and a standard rated invoice with no seller VAT identifier reports BR-S-02.

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 VAT identifier starts with digits

<cac:PartyTaxScheme>
  <cbc:CompanyID>123456789</cbc:CompanyID>
  <cac:TaxScheme>
    <cbc:ID>VAT</cbc:ID>
  </cac:TaxScheme>
</cac:PartyTaxScheme>

Fragment of the corrected invoice: the identifier carries its GB prefix

<cac:PartyTaxScheme>
  <cbc:CompanyID>GB123456789</cbc:CompanyID>
  <cac:TaxScheme>
    <cbc:ID>VAT</cbc:ID>
  </cac:TaxScheme>
</cac:PartyTaxScheme>

Both fragments are the cac:PartyTaxScheme of the seller, inside cac:AccountingSupplierParty/cac:Party. Only cbc:CompanyID differs: 123456789 in the failing file and GB123456789 in the corrected one. The failing document reports only BR-CO-09.

Where it applies

• Applies to UBL Invoice and CreditNote. The same missing prefix in a credit note, on the seller or the buyer, reports the same single finding.
• An empty cbc:CompanyID is not reported by this rule. It is reported as an empty element by PEPPOL-EN16931-R008.
• The prefix on the seller identifier can bring other rules into play. With EL or GR on the seller VAT identifier of an otherwise British test invoice, BR-CO-09 passes and the Peppol layer reports its Greek national rules. The same prefixes on the buyer identifier pass with no findings. National rules are outside this reference.
• Passing shows only that the identifier starts with a listed prefix. It is not a check that the number is valid, exists or belongs to the party.

Related rules

• PEPPOL-EN16931-R008 reports a CompanyID that is present but empty
• BR-CL-25 checks the scheme code when a VAT number is also used as the electronic address
• BR-AE-10 checks the exemption reason on reverse charge documents, where seller and buyer VAT identifiers are both in play
• Browse every rule in the reference

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-20.1: source checked 2026-09-20, explanation last updated 2026-09-20.

The official definition of BR-CO-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.