# BR-G-01: Send exactly one VAT breakdown for export outside the EU

A document with a line, allowance or charge in category `G` needs one VAT breakdown in `G`: none fails, and so does a second copy.

- 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-G-01/
- Explanation last updated: 2026-09-28

## The short answer

`BR-G-01` fails when the document uses category `G` somewhere, on a line, a document-level allowance or a document-level charge, and the root `cac:TaxTotal` does not hold exactly one `cac:TaxSubtotal` in `G`. The failing invoice repeats its export breakdown; delete the copy so that a single `G` breakdown of 25.00 remains.

Export outside the EU always has a rate of 0, so there is never a reason for a second `G` breakdown: every line, allowance and charge in `G` is summed into one.

## What the rule checks

The rule runs once per document and reports at the root. Any `cac:ClassifiedTaxCategory` or `cac:TaxCategory` with `cbc:ID` of `G` under the `VAT` scheme sets it off, which covers items, document-level allowances and charges, and the breakdown itself.

It then counts the `G` categories among the `cac:TaxSubtotal` elements of the root `cac:TaxTotal` and needs exactly 1.

A duplicate is caught here and nowhere else. Each copy of the recorded breakdown equals the 25.00 of the line on its own, so `BR-G-08`, which compares every `G` breakdown with the whole export sum, passes both.

A split is reported twice over. When tried, the freight example divided into a `G` breakdown of 25.00 for the line and one of 4.00 for the charge reported this rule and `BR-G-08` at each breakdown, since neither equals 29.00.

A charge on its own is enough to require the breakdown. When tried, a freight charge of 4.00 in `G` on a Standard rated invoice with no `G` breakdown reported this rule and nothing else.

The reverse is not checked. The breakdown counts as `G` content itself, so when tried, a `G` breakdown of 0.00 added to a Standard rated invoice with no export content passed every layer.

| 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)` |
| BT-95 | Document level allowance VAT category code | `cac:AllowanceCharge[cbc:ChargeIndicator = false]/cac:TaxCategory/cbc:ID` |
| BT-102 | Document level charge VAT category code | `cac:AllowanceCharge[cbc:ChargeIndicator = true]/cac:TaxCategory/cbc:ID` |

## How an integration ends up here

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

- The breakdown is appended once by the tax engine and again by the invoice template.
- Breakdowns are built per source, one for the lines and one for document-level charges, instead of per category.
- Export lines are mapped to a zero-rated tax code when the breakdown is built, so the document has `G` lines under a `Z` breakdown.
- An export freight charge is classified `G` while the breakdown builder only looks at lines.

## How to fix it

1. Collect every line, root-level allowance and root-level charge whose category is `G`.
2. Write one `cac:TaxSubtotal` for them in the root `cac:TaxTotal`, with `cbc:ID` of `G`, `cbc:Percent` of `0`, the reason `VATEX-EU-G`, and lines plus charges minus allowances as its taxable amount.
3. Remove any other `G` breakdown, and any breakdown in another category that has nothing behind it.
4. Where breakdowns are grouped by category and rate, check that no `G` item carries a stray rate, so that grouping cannot produce a second export breakdown.

## Before and after

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

Fragment of the failing invoice: the export breakdown appears twice, 25.00 in each

```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>G</cbc:ID>
      <!-- rate 0, reason VATEX-EU-G, reason text and tax scheme omitted from this fragment -->
    </cac:TaxCategory>
  </cac:TaxSubtotal>
  <cac:TaxSubtotal>
    <cbc:TaxableAmount currencyID="GBP">25.00</cbc:TaxableAmount>
    <cbc:TaxAmount currencyID="GBP">0.00</cbc:TaxAmount>
    <cac:TaxCategory>
      <cbc:ID>G</cbc:ID>
      <!-- rate 0, reason VATEX-EU-G, reason text and tax scheme omitted from this fragment -->
    </cac:TaxCategory>
  </cac:TaxSubtotal>
</cac:TaxTotal>
```

Fragment of the corrected invoice: one export breakdown for the 25.00 export line

```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>G</cbc:ID>
      <cbc:Percent>0</cbc:Percent>
      <cbc:TaxExemptionReasonCode>VATEX-EU-G</cbc:TaxExemptionReasonCode>
      <cbc:TaxExemptionReason>Export outside the EU</cbc:TaxExemptionReason>
      <cac:TaxScheme>
        <cbc:ID>VAT</cbc:ID>
      </cac:TaxScheme>
    </cac:TaxCategory>
  </cac:TaxSubtotal>
</cac:TaxTotal>
```

The failing invoice has two identical `G` breakdowns of 25.00 in its `cac:TaxTotal`; the corrected invoice has one. The failing document reports only `BR-G-01`: each copy matches the export line by itself, and with 0.00 of tax in each, the VAT total of 0.00 still agrees with their sum.

### What the validator reported

- The failing invoice reports **BR-G-01**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.com/finance/rule-examples/BR-G-01-invalid.xml)
  - [Download the corrected XML](https://ironfang.com/finance/rule-examples/export-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`. The duplicated breakdown in a credit note reported the same finding when tried.
- When export lines sit under a breakdown in another category, that category's own checks join this rule. When tried, the export line with its breakdown relabelled `Z`, without the export reason, reported this rule and `BR-Z-08`.
- Removing the only breakdown also reported `BR-CO-18`, `PEPPOL-EN16931-R053` and `PEPPOL-EN16931-R054` when tried, because the document then had no VAT breakdown at all.
- The same count of exactly one applies to other categories under `BR-Z-01`, `BR-E-01`, `BR-AE-01`, `BR-IC-01` and `BR-O-01`. Standard rated content may have one breakdown per rate instead (`BR-S-01`).

## Related rules

- [BR-G-08 checks the taxable amount of the single export breakdown this rule asks for](https://ironfang.com/docs/finance/rules/BR-G-08.md)
- [BR-G-10 requires the export reason in that breakdown](https://ironfang.com/docs/finance/rules/BR-G-10.md)
- [BR-IC-01 is the same count for intra-community supplies](https://ironfang.com/docs/finance/rules/BR-IC-01.md)
- [BR-E-01 applies the same count to exempt breakdowns](https://ironfang.com/docs/finance/rules/BR-E-01.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-G-01](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-G-01/) 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-G-01)
- [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
