# BR-O-14: Keep document level charges in category O on a not subject to VAT invoice

On a document with an `O` VAT breakdown, every document-level charge must be in `O` too. A delivery charge left in `S` at 20 there is rejected.

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

## The short answer

`BR-O-14` fails when an `O` VAT breakdown is present and a charge, a `cac:AllowanceCharge` with `cbc:ChargeIndicator` `true`, has a `cac:TaxCategory` in another category under the `VAT` scheme. The recorded `Delivery` charge of 4.00 is `S` at 20 on an invoice whose line and breakdown are `O`. Recode the charge to `O`, or, if it is really taxable, bill it on a separate invoice.

In the recorded invoice the breakdown does not give the charge away: the charge has no `S` breakdown of its own and the `O` taxable amount leaves it out, so apart from this rule only the Standard rated rules that the charge sets off notice it.

## What the rule checks

The rule starts from an `O` category in `cac:TaxTotal/cac:TaxSubtotal`, then counts charge tax categories under the `VAT` scheme whose `cbc:ID` is not `O`, at any depth in the document. One finding is raised at the root.

A line-level charge counts too. When tried, a charge of 0.00 inside the `O` line, coded `S` at 20, reported this rule, `BR-S-01`, `BR-S-04` and the warning `UBL-CR-558`.

The category chosen changes only the companions of this rule: coded `E` at 0, the delivery charge brought `BR-E-01` and `BR-E-04`, and coded `Z` at 0 it brought `BR-Z-01` and `BR-Z-04`, when tried.

The breakdown amount decides whether `BR-O-08` joins in. Recoding the charge alone, with the `O` taxable amount left at 29.00, reported that rule too when tried, since the `O` content had fallen to 25.00.

| Term | Meaning | UBL element |
|---|---|---|
| BG-21 | Document level charges | `cac:AllowanceCharge[cbc:ChargeIndicator = true]` |
| BT-102 | Document level charge VAT category code | `cac:AllowanceCharge[cbc:ChargeIndicator = true]/cac:TaxCategory/cbc:ID` |
| BT-118 | VAT category code | `cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory/cbc:ID` |

## How an integration ends up here

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

- The delivery charge is a stock item in the invoicing system with the Standard rate attached, used on every invoice.
- The seller moved its invoices to `O` but updated only the product catalogue, not the list of charges.
- A carrier or marketplace adds the charge with its own VAT settings after the document has been built.

## How to fix it

1. Decide the VAT treatment of the charge. If it belongs to supplies that are outside the scope of VAT, as the delivery of the out-of-scope item does here, it is `O` as well.
2. Set the charge's `cac:TaxCategory/cbc:ID` to `O` and remove its `cbc:Percent`, which `BR-O-07` forbids in `O`.
3. Include the charge in the `O` breakdown: the taxable amount becomes 25.00 + 4.00 = 29.00, the same as `cbc:TaxExclusiveAmount`.
4. If the charge is taxable, invoice it separately with its own Standard rated breakdown and the seller VAT identifier that category needs, and take its 4.00 out of this invoice's totals.

## 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 Standard rated delivery charge on a document whose only breakdown is O

```xml
<cac:AllowanceCharge>
  <cbc:ChargeIndicator>true</cbc:ChargeIndicator>
  <cbc:AllowanceChargeReasonCode>FC</cbc:AllowanceChargeReasonCode>
  <cbc:AllowanceChargeReason>Delivery</cbc:AllowanceChargeReason>
  <cbc:Amount currencyID="GBP">4.00</cbc:Amount>
  <cac:TaxCategory>
    <cbc:ID>S</cbc:ID>
    <cbc:Percent>20</cbc:Percent>
    <cac:TaxScheme>
      <cbc:ID>VAT</cbc:ID>
    </cac:TaxScheme>
  </cac:TaxCategory>
</cac:AllowanceCharge>
<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>
```

Fragment of the corrected invoice: the delivery charge is in O and counted in the O breakdown

```xml
<cac:AllowanceCharge>
  <cbc:ChargeIndicator>true</cbc:ChargeIndicator>
  <cbc:AllowanceChargeReasonCode>FC</cbc:AllowanceChargeReasonCode>
  <cbc:AllowanceChargeReason>Delivery</cbc:AllowanceChargeReason>
  <cbc:Amount currencyID="GBP">4.00</cbc:Amount>
  <cac:TaxCategory>
    <cbc:ID>O</cbc:ID>
    <cac:TaxScheme>
      <cbc:ID>VAT</cbc:ID>
    </cac:TaxScheme>
  </cac:TaxCategory>
</cac:AllowanceCharge>
<cac:TaxTotal>
  <cbc:TaxAmount currencyID="GBP">0.00</cbc:TaxAmount>
  <cac:TaxSubtotal>
    <cbc:TaxableAmount currencyID="GBP">29.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 codes the 4.00 `Delivery` charge `S` with `cbc:Percent` `20` and leaves it out of the `O` taxable amount, which reads 25.00; the corrected invoice has the charge in `O` without a rate and an `O` taxable amount of 29.00. Both differences are deliberate: the `O` taxable amount was lowered to 25.00, the `O` content left once the charge is recoded, so that `BR-O-08` does not join the findings. As well as `BR-O-14`, the failing document reports `BR-S-01`, because Standard rated content needs a Standard rated breakdown, and `BR-S-04`, because a Standard rated charge needs a seller VAT identifier, a tax registration identifier or a tax representative.

### What the validator reported

- The failing invoice reports **BR-O-14**, [BR-S-01](https://ironfang.com/docs/finance/rules/BR-S-01.md) and [BR-S-04](https://ironfang.com/docs/finance/rules/BR-S-04.md). The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.com/finance/rule-examples/BR-O-14-invalid.xml)
  - [Download the corrected XML](https://ironfang.com/finance/rule-examples/outside-scope-charge-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`. Rewritten as a credit note, the failing invoice reported the same three rules when tried.
- The set is complete with `BR-O-11` for breakdowns, `BR-O-12` for lines and `BR-O-13` for allowances; an `O` document that passes all four has no other VAT category in it.

## Related rules

- [BR-O-13 is the matching rule for document level allowances](https://ironfang.com/docs/finance/rules/BR-O-13.md)
- [BR-S-04 is reported here because a Standard rated charge needs a seller identifier for VAT or tax](https://ironfang.com/docs/finance/rules/BR-S-04.md)
- [BR-O-07 forbids the rate once the charge is back in category O](https://ironfang.com/docs/finance/rules/BR-O-07.md)
- [BR-O-11 rejects the Standard rated breakdown that such a charge would otherwise need](https://ironfang.com/docs/finance/rules/BR-O-11.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-28.1: source checked 2026-09-28, explanation last updated 2026-09-28.

[The official definition of BR-O-14](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-O-14/) 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.com/docs/finance/rules/BR-O-14)
- [Free Peppol invoice validator](https://ironfang.com/tools/peppol-validator)
- [Rule index](https://ironfang.com/docs/finance/rules.md)
- [Ironfang Finance API docs](https://ironfang.com/docs/finance)
- The same rule is available to MCP clients as the tool `finance.rule.get` on https://mcp.ironfang.com/mcp