BR-O-04: Remove VAT identifiers when a document level charge is not subject to VAT

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.

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.

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 delivery charge is in 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 omitted from this fragment -->
<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>

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

<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>
<!-- buyer and the delivery charge of 4.00 in category O, unchanged, omitted from this fragment -->

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.

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
• BR-O-07 keeps a VAT rate off the not subject to VAT charge itself
• BR-O-02 is reported with this rule whenever the lines are also not subject to VAT
• BR-CO-26 needs the seller identified another way once its VAT identifier is removed
• 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-28.1: source checked 2026-09-28, explanation last updated 2026-09-28.

The official definition of 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.