# BR-O-11: Keep amounts not subject to VAT on a separate invoice from other VAT categories

A document with a VAT breakdown in category `O` may not have a breakdown in any other category. Out-of-scope and VAT-rated amounts need separate documents.

- Layer: EN 16931
- Severity: fatal (the document is invalid)
- Topics: VAT
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-O-11/
- Explanation last updated: 2026-09-24

## The short answer

`BR-O-11` fails when `cac:TaxTotal` holds a `cac:TaxSubtotal` in category `O` and also one in any other category under the `VAT` scheme; the recorded example adds a Standard rated breakdown at 20% beside the `O` one. Take the other-category lines off the document and invoice them separately, so each document is either wholly not subject to VAT or has no `O` at all.

No arrangement of the XML makes the mixture valid. The EN 16931 rules reserve `O` for a document entirely outside VAT, so a document that is only partly outside the scope of VAT cannot be expressed with `O`.

## What the rule checks

The rule reads the document-level breakdown only. Once any `cac:TaxSubtotal/cac:TaxCategory` under the `VAT` scheme has `cbc:ID` of `O`, the count of breakdowns under that scheme with a different `cbc:ID` must be zero. One finding is raised at the root.

Lines are covered by `BR-O-12`, which rejects a line in another category on a document with an `O` breakdown. With the Standard rated breakdown removed but its line kept, this rule passed when tried, and `BR-O-12` failed together with `BR-S-01` and `BR-S-02`.

It works the other way too: a Standard rated breakdown beside `O` lines, with no Standard rated line behind it, still reported `BR-O-11` when tried, among findings about the unsupported breakdown.

Any second category counts, not just `S`. An exempt line and breakdown in place of the Standard rated ones reported this rule, `BR-O-12`, and `BR-E-02` for the missing seller VAT identifier.

Two `O` breakdowns are not counted against this rule, but that document was rejected by `BR-O-01` and `BR-O-08` when tried.

| Term | Meaning | UBL element |
|---|---|---|
| BG-23 | VAT breakdown | `cac:TaxTotal/cac:TaxSubtotal` |
| BT-118 | VAT category code | `cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory/cbc:ID` |
| 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)` |

## How an integration ends up here

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

- A single invoice combines a taxable sale with an item that the source system marks as outside the scope of VAT, and the export writes one breakdown per category it finds.
- Items with no tax code default to `O`, so an ordinary Standard rated invoice picks up an `O` line and breakdown by accident.
- A seller that is not VAT registered uses `O` throughout, but one product or charge still carries a Standard rated tax code from a template or price list.

## How to fix it

1. Find out why each line has its category. If the `O` line comes from a default for a missing tax code, correct the tax code at source; the document may then need no `O` at all.
2. If both kinds of supply are real, issue two documents: one with only the `O` lines and the `O` breakdown, without VAT identifiers, and one with the other lines, their breakdowns and the VAT identifiers those categories require.
3. Recalculate every total on each document. In the recorded example, taking the Standard rated line away brings the line total from 35.00 to 25.00, the VAT total from 2.00 to 0.00 and the amount due from 37.00 to 25.00.
4. Do not relabel the taxable line as `O` to get past the rule. The category states the VAT treatment, and changing it misstates the supply.

## Before and after

These are fragments, not complete documents. The complete synthetic documents they come from are linked below.

Fragment of the failing invoice: an O breakdown and a Standard rated breakdown in the same VAT total

```xml
<cac:TaxTotal>
  <cbc:TaxAmount currencyID="GBP">2.00</cbc:TaxAmount>
  <cac:TaxSubtotal>
    <cbc:TaxableAmount currencyID="GBP">25.00</cbc:TaxableAmount>
    <cbc:TaxAmount currencyID="GBP">0.00</cbc:TaxAmount>
    <cac:TaxCategory>
      <cbc:ID>O</cbc:ID>
      <!-- reason code and text omitted from this fragment -->
      <cac:TaxScheme>
        <cbc:ID>VAT</cbc:ID>
      </cac:TaxScheme>
    </cac:TaxCategory>
  </cac:TaxSubtotal>
  <cac:TaxSubtotal>
    <cbc:TaxableAmount currencyID="GBP">10.00</cbc:TaxableAmount>
    <cbc:TaxAmount currencyID="GBP">2.00</cbc:TaxAmount>
    <cac:TaxCategory>
      <cbc:ID>S</cbc:ID>
      <cbc:Percent>20</cbc:Percent>
      <cac:TaxScheme>
        <cbc:ID>VAT</cbc:ID>
      </cac:TaxScheme>
    </cac:TaxCategory>
  </cac:TaxSubtotal>
</cac:TaxTotal>
<!-- line 1 in category O at 25.00 and line 2 in category S at 20 for 10.00 omitted from this fragment -->
```

Fragment of the corrected invoice: only the O breakdown remains, with no VAT

```xml
<cac:TaxTotal>
  <cbc:TaxAmount currencyID="GBP">0.00</cbc:TaxAmount>
  <cac:TaxSubtotal>
    <cbc:TaxableAmount currencyID="GBP">25.00</cbc:TaxableAmount>
    <cbc:TaxAmount currencyID="GBP">0.00</cbc:TaxAmount>
    <cac:TaxCategory>
      <cbc:ID>O</cbc:ID>
      <!-- reason code and text omitted from this fragment -->
      <cac:TaxScheme>
        <cbc:ID>VAT</cbc:ID>
      </cac:TaxScheme>
    </cac:TaxCategory>
  </cac:TaxSubtotal>
</cac:TaxTotal>
```

The failing invoice adds a second line, `Example standard rated item` at 10.00 in category `S` at 20%, with a matching Standard rated breakdown and totals raised to 35.00 net, 2.00 VAT and 37.00 due; the corrected invoice has only the `O` line and breakdown. The failing document reports three findings. `BR-O-11` is the conflict between the breakdowns. `BR-O-12` is the same conflict on the lines, since an `S` line sits on a document with an `O` breakdown. `BR-S-02` appears because a Standard rated line needs a seller VAT or tax registration identifier and this seller has none; adding a seller VAT identifier, when tried, cleared `BR-S-02` and brought `BR-O-02`, which forbids that identifier. The clash is the lesson: the mixed document cannot be made valid.

### What the validator reported

- The failing invoice reports **BR-O-11**, `BR-O-12` and [BR-S-02](https://ironfang.uk/docs/finance/rules/BR-S-02.md). The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/BR-O-11-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`. As a credit note, the failing invoice gave the same three findings when tried.
- Identifiers cannot rescue a mixed document. When tried, a seller tax registration under the scheme `TAX` cleared `BR-S-02` without setting off `BR-O-02`, and `BR-O-11` and `BR-O-12` still failed.
- After a split, each document has to balance on its own: `BR-CO-10`, `BR-CO-13`, `BR-CO-14` and `BR-CO-15` check its totals.

## Related rules

- [BR-O-02 forbids the VAT identifiers that the other categories on a mixed document would need](https://ironfang.uk/docs/finance/rules/BR-O-02.md)
- [BR-S-02 is reported beside this rule when the added line is Standard rated and the seller has no VAT identifier](https://ironfang.uk/docs/finance/rules/BR-S-02.md)
- [BR-S-01 requires a Standard rated breakdown for Standard rated lines, so dropping only the breakdown does not help](https://ironfang.uk/docs/finance/rules/BR-S-01.md)
- [BR-CO-14 checks the VAT total against the breakdowns once the documents are split](https://ironfang.uk/docs/finance/rules/BR-CO-14.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-11](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-O-11/) 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-11)
- [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
