# BR-O-02: Remove VAT identifiers from a document that is not subject to VAT
When a line is category `O`, not subject to VAT, the document must not carry a VAT identifier for the seller, the buyer or a tax representative.
- Layer: EN 16931
- Severity: fatal (the document is invalid)
- Topics: VAT, Parties and addresses
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-O-02/
- Explanation last updated: 2026-09-24
## 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.
| Term | Meaning | UBL element |
|---|---|---|
| BT-151 | Invoiced item VAT category code | `cac:InvoiceLine/cac:Item/cac:ClassifiedTaxCategory/cbc:ID (cac:CreditNoteLine/cac:Item/cac:ClassifiedTaxCategory/cbc:ID in a credit note)` |
| BT-31 | Seller VAT identifier | `cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID` |
| BT-63 | Seller tax representative VAT identifier | `cac:TaxRepresentativeParty/cac:PartyTaxScheme/cbc:CompanyID` |
| BT-48 | Buyer VAT identifier | `cac:AccountingCustomerParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID` |
## 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.
## 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
```xml
7300010000001
GB123456789
VAT
Example Supplier Ltd
12345678
O
VAT
```
Fragment of the corrected invoice: the seller is identified by its legal registration number only
```xml
7300010000001
Example Supplier Ltd
12345678
```
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`.
### What the validator reported
- The failing invoice reports **BR-O-02**. The corrected document passes every layer with no findings.
- [Download the failing XML](https://ironfang.uk/finance/rule-examples/BR-O-02-invalid.xml)
- [Download the corrected XML](https://ironfang.uk/finance/rule-examples/not-subject-valid.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
- 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](https://ironfang.uk/docs/finance/rules/BR-O-11.md)
- [BR-CO-26 still requires a seller identifier once the VAT identifier is gone](https://ironfang.uk/docs/finance/rules/BR-CO-26.md)
- [BR-S-02 requires the seller identifier that this rule forbids, when a line is Standard rated](https://ironfang.uk/docs/finance/rules/BR-S-02.md)
## 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](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/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.
## Links
- [This rule as a web page](https://ironfang.uk/docs/finance/rules/BR-O-02)
- [Free Peppol invoice validator](https://ironfang.uk/tools/peppol-validator)
- [Rule index](https://ironfang.uk/docs/finance/rules.md)
- [Ironfang Finance API docs](https://ironfang.uk/docs/finance)
- The same rule is available to MCP clients as the tool `finance.rule.get` on https://mcp.ironfang.uk/mcp