BR-O-02: Remove VAT identifiers from a document that is not subject to VAT

The short answer

BR-O-02 fails when a line is classified O, not subject to VAT, and the document also holds a VAT identifier: a cbc:CompanyID in a VAT cac:PartyTaxScheme under the seller, the buyer or cac:TaxRepresentativeParty. In the recorded example it is the seller identifier GB123456789. Remove the VAT cac:PartyTaxScheme from every party, or, if the invoice has to show VAT numbers, question whether O is the right category.

This runs against instinct, since rules for other VAT categories, such as BR-S-02 and BR-IC-02, ask for VAT identifiers rather than forbid them. The EN 16931 rules treat a document with O lines as wholly outside the VAT system: no other VAT category may sit beside it, and no party may be identified for VAT on it. Even the buyer VAT number, which is a fact about the buyer, is forbidden.

What the rule checks

One O line is enough to apply the rule: any cac:ClassifiedTaxCategory with cbc:ID of O under the VAT scheme. There is a single finding at the root, however many identifiers are present; seller and buyer together gave one finding when tried.

Three parties are checked, each only for a cac:PartyTaxScheme whose cac:TaxScheme/cbc:ID is VAT: the seller, the buyer and the tax representative. When tried, a buyer VAT identifier on its own and a tax representative VAT identifier on its own each reported BR-O-02.

It is the element, not its content, that fails. An empty seller cbc:CompanyID in a VAT cac:PartyTaxScheme still reported BR-O-02 when tried, with PEPPOL-EN16931-R008 beside it.

Registrations outside the VAT scheme are left alone. A seller cac:PartyTaxScheme under the scheme TAX, the place for a non-VAT tax registration, gave a valid document when tried. Legal registration identifiers in cac:PartyLegalEntity are not touched either; the recorded example keeps one for each party.

How an integration ends up here

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

• The seller VAT identifier is added to every outgoing document from company settings, whatever the categories on the lines.
• The buyer VAT number is copied from the customer record by default, including on documents with only O lines.
• A line the source system marks as outside the scope of VAT is sent as O inside an otherwise VAT-bearing invoice, where the identifiers the rest of the invoice needs become forbidden.
• A mapping default turns items without a tax code into O, so a VAT-registered seller ends up with an O line it never intended.

How to fix it

1. Decide first whether the whole document is outside the scope of VAT. If it also has taxable content, or the seller must show its VAT number on it, then O is the problem and needs a decision from whoever owns tax determination; BR-O-11 rejects O mixed with other categories in any case.
2. If the document really is not subject to VAT, remove every cac:PartyTaxScheme whose cac:TaxScheme/cbc:ID is VAT from cac:AccountingSupplierParty/cac:Party, cac:AccountingCustomerParty/cac:Party and cac:TaxRepresentativeParty. Emptying the value while keeping the element does not work.
3. Keep the seller identifiable in another way, as BR-CO-26 requires: a legal registration identifier in cac:PartyLegalEntity/cbc:CompanyID or a seller identifier in cac:PartyIdentification/cbc:ID. A VAT identifier added for that purpose brings this rule straight back.
4. Build the behaviour into the mapping: when any line is O, suppress the VAT cac:PartyTaxScheme for all parties, rather than editing single invoices.

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: a seller VAT identifier on a document whose only line is category O

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

<!-- buyer, totals and the start of line 1 omitted from this fragment -->
<cac:ClassifiedTaxCategory>
  <cbc:ID>O</cbc:ID>
  <cac:TaxScheme>
    <cbc:ID>VAT</cbc:ID>
  </cac:TaxScheme>
</cac:ClassifiedTaxCategory>

Fragment of the corrected invoice: the seller is identified by its legal registration number only

<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 failing invoice has a seller cac:PartyTaxScheme with GB123456789 under the VAT scheme; the corrected invoice has no VAT identifier for any party, and both keep the same O line and breakdown. The failing document reports only BR-O-02. Without the VAT identifier the corrected one still passes BR-CO-26, thanks to the seller legal registration identifier 12345678.

Where it applies

• Applies to UBL Invoice and CreditNote. Turned into a credit note, the failing invoice reported this rule alone when tried.
• With a Standard rated line beside the O line, the identifier rules pull in opposite directions: BR-S-02 wants a seller identifier that this rule forbids when it is a VAT one. BR-O-11 rejects the mixture itself.
• The rule reads only the line categories and the party tax schemes. It does not know whether the seller is actually registered for VAT, so a clean result says nothing about that.

Related rules

• BR-O-11 forbids other VAT categories on a not subject to VAT document, the other half of the same all-or-nothing design
• BR-CO-26 still requires a seller identifier once the VAT identifier is gone
• BR-S-02 requires the seller identifier that this rule forbids, when a line is Standard rated
• 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-O-02 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.