# BR-O-04: Remove VAT identifiers when a document level charge is not subject to VAT
A document-level charge in category `O`, such as delivery on an out-of-scope invoice, means no party on that document may carry a VAT identifier.
- Layer: EN 16931
- Severity: fatal (the document is invalid)
- Topics: VAT, Allowances and charges, Parties and addresses
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-O-04/
- Explanation last updated: 2026-09-28
## The short answer
`BR-O-04` fails when a root-level `cac:AllowanceCharge` with `cbc:ChargeIndicator` `true` is in category `O` and the seller, the buyer or the tax representative has a `cbc:CompanyID` in a `VAT` `cac:PartyTaxScheme`. The recorded example charges `Delivery` at 4.00 in `O` while the seller shows `GB123456789`. Delete the VAT identifiers, or reconsider whether the charge and the invoice belong in `O` at all.
A seller that has to print its VAT number is telling the buyer it trades inside the VAT system. In that case check whether the delivery should follow the category of the goods it delivers, rather than sit in `O`.
## What the rule checks
Only charges at the document root with `cbc:ChargeIndicator` `true` and a `cac:TaxCategory` of `O` under the `VAT` scheme set the rule off; a charge inside a line does not. The identifiers it then looks for are the same three as for `O` lines and allowances.
Each forbidden party was tried on the corrected invoice: the seller identifier `GB123456789`, a buyer identifier `GB987654321` and a tax representative with `GB987654321` each reported this rule, every time beside `BR-O-02`.
On a Standard rated invoice the rule appears without `BR-O-02`. When tried, a 4.00 delivery charge in `O` added to an invoice with an `S` line and the seller identifier `GB123456789` reported this rule and `BR-O-01`.
Tax registrations under another scheme are left alone. With the seller identified as `1234567890` under `TAX` in place of the VAT identifier, the charge document stayed valid when tried.
| Term | Meaning | UBL element |
|---|---|---|
| BT-102 | Document level charge VAT category code | `cac:AllowanceCharge[cbc:ChargeIndicator = true]/cac:TaxCategory/cbc:ID` |
| BT-31 | Seller VAT identifier | `cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID` |
| BT-48 | Buyer VAT identifier | `cac:AccountingCustomerParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID` |
| BT-63 | Seller tax representative VAT identifier | `cac:TaxRepresentativeParty/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 number is written from company settings onto every invoice, and the delivery charge was set to `O` because the whole order was.
- A delivery charge passed on at cost is treated as outside the scope of VAT in the source system, while the rest of the invoice is taxable and carries the VAT numbers.
- Charges without a tax code of their own fall back to `O` in the mapping, on invoices from a VAT-registered seller.
## How to fix it
1. Decide whether the charge is really outside the scope of VAT. A charge for delivering taxable goods usually shares their VAT treatment; then the charge category is what is wrong, and `BR-O-14` follows if the lines stay in `O`.
2. If the whole document is outside the scope of VAT, remove the `VAT` `cac:PartyTaxScheme` from `cac:AccountingSupplierParty/cac:Party`, and from the buyer and the tax representative if they have one.
3. Keep the legal registration identifier `12345678` in `cac:PartyLegalEntity/cbc:CompanyID`, so the seller is still identified as `BR-CO-26` requires.
4. Test the whole document for `O` in the mapping, charges included, before deciding to write VAT identifiers.
## 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 delivery charge is in category O
```xml
7300010000001
GB123456789
VAT
Example Supplier Ltd
12345678
true
FC
Delivery
4.00
O
VAT
```
Fragment of the corrected invoice: the seller is identified by its legal registration number alone
```xml
7300010000001
Example Supplier Ltd
12345678
```
The failing invoice gives the seller a `VAT` `cac:PartyTaxScheme` with `GB123456789`; the corrected invoice identifies the seller only by `12345678` in `cac:PartyLegalEntity`, and both documents keep the `Delivery` charge of 4.00 and the line in `O`. Besides `BR-O-04`, the failing document reports `BR-O-02`, which objects to the same seller identifier because of the `O` line.
### What the validator reported
- The failing invoice reports [BR-O-02](https://ironfang.com/docs/finance/rules/BR-O-02.md) and **BR-O-04**. The corrected document passes every layer with no findings.
- [Download the failing XML](https://ironfang.com/finance/rule-examples/BR-O-04-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`; converted to a credit note, the failing invoice gave `BR-O-02` and `BR-O-04` again when tried.
- Document-level allowances have the twin rule `BR-O-03`. The charge in `O` must also have no rate under `BR-O-07` and is added into the `O` taxable amount checked by `BR-O-08`.
## Related rules
- [BR-O-03 is the same identifier ban for a document level allowance in category O](https://ironfang.com/docs/finance/rules/BR-O-03.md)
- [BR-O-07 keeps a VAT rate off the not subject to VAT charge itself](https://ironfang.com/docs/finance/rules/BR-O-07.md)
- [BR-O-02 is reported with this rule whenever the lines are also not subject to VAT](https://ironfang.com/docs/finance/rules/BR-O-02.md)
- [BR-CO-26 needs the seller identified another way once its VAT identifier is removed](https://ironfang.com/docs/finance/rules/BR-CO-26.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-04](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-O-04/) 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-04)
- [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