BR-CO-26: Give the seller a VAT, legal registration or seller identifier

The short answer

BR-CO-26 fails when cac:AccountingSupplierParty/cac:Party has none of three identifiers: a cbc:CompanyID in a VAT cac:PartyTaxScheme, a cac:PartyIdentification/cbc:ID whose scheme is not SEPA, or a cac:PartyLegalEntity/cbc:CompanyID. Add whichever the seller really has; in the recorded example it is the legal registration identifier 12345678.

On a not subject to VAT document, like the recorded one, the VAT identifier is not available: BR-O-02 forbids it. Use the legal registration identifier or a seller identifier there.

What the rule checks

The rule runs on cac:AccountingSupplierParty and reports there. Only the seller party is read: on an export with a tax representative VAT identifier and no seller identifier of any kind, BR-G-02 passed when tried but BR-CO-26 still failed.

The VAT route needs a cac:PartyTaxScheme with cac:TaxScheme/cbc:ID of VAT and a cbc:CompanyID. A seller registration under the scheme TAX, where a non-VAT tax registration goes, does not count: added to the failing invoice, it left the rule failing when tried.

The seller identifier route takes cac:PartyIdentification/cbc:ID with any schemeID except SEPA, or with none. When tried, SUPPLIER-001 without a scheme and the GLN 7300010000001 with scheme 0088 each gave a valid document. A SEPA identifier alone failed, because under that scheme the element is the creditor identifier for direct debits; next to a second, non-SEPA identifier it passed.

The legal registration route takes cac:PartyLegalEntity/cbc:CompanyID, with or without a schemeID; a value with scheme 0088 passed when tried.

Nothing else stands in. The failing invoice has an electronic address in cbc:EndpointID and a cbc:RegistrationName, and a cac:PartyName added to it also failed when tried.

Presence satisfies the rule. An empty cbc:CompanyID in cac:PartyLegalEntity, or an empty cac:PartyIdentification/cbc:ID, passed it when tried and was reported by PEPPOL-EN16931-R008 instead.

How an integration ends up here

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

• The seller VAT identifier was taken out, for example to clear BR-O-02 on a not subject to VAT invoice, and nothing else identified the seller.
• The company registration number is kept in company settings but mapped only to the printed invoice, not to cac:PartyLegalEntity.
• The only cac:PartyIdentification is the direct debit creditor identifier with scheme SEPA.
• The seller has no VAT registration and the export writes seller identifiers only when a VAT number exists.
• The mapping treats the Peppol electronic address in cbc:EndpointID as the seller identification.

How to fix it

1. Choose from the registrations the seller actually holds: a company registration number, such as a Companies House number for a UK company; a VAT identifier where the document allows one; or an identifier such as a GLN under its ICD scheme.
2. For a registration number, write cbc:CompanyID inside cac:PartyLegalEntity, after cbc:RegistrationName. For a seller identifier, add cac:PartyIdentification with cbc:ID after cbc:EndpointID and before cac:PostalAddress.
3. Mind the scheme rules on cac:PartyIdentification/cbc:ID if you send a schemeID: a scheme outside the ISO 6523 ICD list reported BR-CL-10 when tried, and a GLN with a wrong check digit under 0088 reported PEPPOL-COMMON-R040.
4. On a document with O lines, do not reach for the VAT identifier: when tried, it cleared BR-CO-26 and brought BR-O-02 in its place.

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 has a name and an electronic address but no identifier

<cac:AccountingSupplierParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
    <!-- postal address omitted from this fragment -->
    <cac:PartyLegalEntity>
      <cbc:RegistrationName>Example Supplier Ltd</cbc:RegistrationName>
    </cac:PartyLegalEntity>
  </cac:Party>
</cac:AccountingSupplierParty>

Fragment of the corrected invoice: the legal registration identifier follows the registration name

<cac:AccountingSupplierParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
    <!-- postal address omitted from this fragment -->
    <cac:PartyLegalEntity>
      <cbc:RegistrationName>Example Supplier Ltd</cbc:RegistrationName>
      <cbc:CompanyID>12345678</cbc:CompanyID>
    </cac:PartyLegalEntity>
  </cac:Party>
</cac:AccountingSupplierParty>

The corrected invoice has cbc:CompanyID 12345678 in the seller cac:PartyLegalEntity; the failing invoice has the registration name alone. Neither document gives the seller a VAT identifier or a cac:PartyIdentification, because the invoice is not subject to VAT, so the legal registration identifier is all that identifies the seller. The failing document reports only BR-CO-26, although the seller keeps its electronic address.

Where it applies

• Applies to UBL Invoice and CreditNote. The failing invoice as a credit note reported BR-CO-26 at the seller party when tried.
• The rule has no condition on VAT categories: every document needs one of the three seller identifiers, whether or not VAT is charged.
• National rules can narrow the choice. For suppliers in the Netherlands, NL-R-003 limits which schemes the legal registration identifier may use.

Related rules

• BR-O-02 removes the VAT identifier as an option when a line is not subject to VAT
• BR-CL-10 checks that a seller identifier in cac:PartyIdentification uses a listed scheme
• NL-R-003 restricts the legal registration identifier scheme for Dutch suppliers
• BR-G-02 needs a seller VAT identifier on exports, which a legal registration identifier cannot replace
• 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-CO-26 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.