# BR-G-04: Register the seller under the VAT scheme on an export invoice with a charge in category G

A document-level charge in category `G`, such as freight on an export, needs a seller or tax representative VAT identifier under the `VAT` scheme.

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

## The short answer

`BR-G-04` fails when a `cac:AllowanceCharge` with `cbc:ChargeIndicator` of `true` is in category `G` and there is no VAT identifier for the seller or its tax representative. The recorded seller does send `GB123456789`, but under the tax scheme `TAX`, which does not count; change the scheme to `VAT`.

The freight charge of 4.00 and the export line share one seller, so `BR-G-02` reports the same shortfall for the line.

## What the rule checks

A charge in `G` sets the rule off with no export line at all. When tried, a freight charge of 4.00 in `G` on an invoice whose only line was Standard rated at 20%, with the seller registered only under `TAX`, reported this rule alone. A charge inside a line counts as well: when tried, a charge of 0.00 in `G` placed in that Standard rated line, again with the seller only under `TAX`, reported this rule and the warning `UBL-CR-558`.

The seller identifier must sit in a `cac:PartyTaxScheme` whose `cac:TaxScheme/cbc:ID` is `VAT`. The scheme is the whole difference between the failing and corrected invoices: the same `GB123456789` under `TAX` fails.

A tax representative is an alternative. When tried, the freight invoice with no seller VAT identifier but a `cac:TaxRepresentativeParty` holding `GB987654321` under `VAT` passed every layer.

An empty identifier is not reported here. When tried, a seller `cbc:CompanyID` with no content under `VAT` got past this rule and `BR-G-02`, and failed only `PEPPOL-EN16931-R008`.

| 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-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:

- Tax registrations are exported with one generic scheme code, `TAX`, whatever kind of registration they are.
- The seller VAT section is suppressed for buyers outside the EU, on the reasoning that no VAT is charged.
- Freight is added as a separate charge by a logistics module that assigns `G` from the destination, while the seller party comes from a profile with no VAT registration.

## How to fix it

1. Find where the seller `cac:PartyTaxScheme` is written, and give it a `cac:TaxScheme/cbc:ID` of `VAT` when its `cbc:CompanyID` is the VAT registration number.
2. If the seller also has a tax registration that is not for VAT, it can go in a second `cac:PartyTaxScheme` under another scheme; the `VAT` one must still be there.
3. Where a tax representative accounts for VAT on the seller's behalf, add `cac:TaxRepresentativeParty` with its own `VAT` `cac:PartyTaxScheme` instead.
4. Leave the freight charge in `G` at a rate of `0` if it is part of the export 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: a freight charge in category G, and the seller registration under TAX

```xml
<cac:AccountingSupplierParty>
  <cac:Party>
    <!-- endpoint and postal address in London, GB, omitted from this fragment -->
    <cac:PartyTaxScheme>
      <cbc:CompanyID>GB123456789</cbc:CompanyID>
      <cac:TaxScheme>
        <cbc:ID>TAX</cbc:ID>
      </cac:TaxScheme>
    </cac:PartyTaxScheme>
    <!-- legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingSupplierParty>
<!-- buyer in New York, US, omitted from this fragment -->
<cac:AllowanceCharge>
  <cbc:ChargeIndicator>true</cbc:ChargeIndicator>
  <cbc:AllowanceChargeReasonCode>FC</cbc:AllowanceChargeReasonCode>
  <cbc:AllowanceChargeReason>Freight to New York</cbc:AllowanceChargeReason>
  <cbc:Amount currencyID="GBP">4.00</cbc:Amount>
  <cac:TaxCategory>
    <cbc:ID>G</cbc:ID>
    <cbc:Percent>0</cbc:Percent>
    <!-- tax scheme VAT omitted from this fragment -->
  </cac:TaxCategory>
</cac:AllowanceCharge>
```

Fragment of the corrected invoice: the same registration under the VAT scheme

```xml
<cac:AccountingSupplierParty>
  <cac:Party>
    <!-- endpoint and postal address in London, GB, omitted from this fragment -->
    <cac:PartyTaxScheme>
      <cbc:CompanyID>GB123456789</cbc:CompanyID>
      <cac:TaxScheme>
        <cbc:ID>VAT</cbc:ID>
      </cac:TaxScheme>
    </cac:PartyTaxScheme>
    <!-- legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingSupplierParty>
<!-- buyer and the freight charge of 4.00 in G omitted from this fragment -->
```

Only the seller tax scheme differs: `TAX` in the failing invoice, `VAT` in the corrected one, both around `GB123456789`. The freight charge of 4.00 in `G` is unchanged. The failing document also reports `BR-G-02`, since its export line needs the same seller VAT identifier.

### What the validator reported

- The failing invoice reports [BR-G-02](https://ironfang.com/docs/finance/rules/BR-G-02.md) and **BR-G-04**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.com/finance/rule-examples/BR-G-04-invalid.xml)
  - [Download the corrected XML](https://ironfang.com/finance/rule-examples/export-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`. The failing invoice as a credit note reported `BR-G-02` and this rule when tried.
- Allowances in `G` are checked the same way by `BR-G-03`. The charge's own rate must be 0 under `BR-G-07`, and its amount counts towards the export taxable amount checked by `BR-G-08`.
- `BR-CO-09` reads only identifiers under the `VAT` scheme, so moving `GB123456789` to `VAT` also brings its country prefix under that check.

## Related rules

- [BR-G-03 is the same check for a document-level allowance in category G](https://ironfang.com/docs/finance/rules/BR-G-03.md)
- [BR-G-07 requires the G charge to have a rate of 0](https://ironfang.com/docs/finance/rules/BR-G-07.md)
- [BR-G-02 asks for the seller VAT identifier when an export line is present, and fires with this rule](https://ironfang.com/docs/finance/rules/BR-G-02.md)
- [BR-S-02 accepts a seller registration under TAX for Standard rated lines, unlike this rule](https://ironfang.com/docs/finance/rules/BR-S-02.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-04](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-G-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-G-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