# BR-G-02: Add the seller VAT identifier to an export invoice

A document with a line in category `G`, export outside the EU, needs a seller VAT identifier, or a tax representative one, under the `VAT` scheme.

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

## The short answer

`BR-G-02` fails when a line is classified `G`, export outside the EU, and the seller has no VAT identifier: no `cbc:CompanyID` in a `VAT` `cac:PartyTaxScheme` under `cac:AccountingSupplierParty/cac:Party`, and no tax representative carrying one. Add the seller VAT identifier.

Only the seller side is checked. The recorded export goes to a buyer in the United States with no VAT identifier, and that is accepted.

## What the rule checks

Any `cac:ClassifiedTaxCategory` with `cbc:ID` of `G` under the `VAT` scheme sets the rule off. In UBL that element exists only on items, so the lines decide; a `G` breakdown alone does not. One finding is raised at the root.

It passes with a seller `cac:PartyTaxScheme` whose `cac:TaxScheme/cbc:ID` is `VAT` and which has a `cbc:CompanyID`, or with the same inside `cac:TaxRepresentativeParty`. When tried, a tax representative with name, address and a `VAT` identifier made the export valid without any seller VAT identifier.

Other seller identifiers do not count. The failing invoice keeps the legal registration identifier `12345678` and fails. A seller `cac:PartyTaxScheme` under the scheme `TAX`, where a non-VAT tax registration belongs, also failed when tried, whether it held `GB123456789` or a local tax number; `BR-S-02` would accept that registration on a Standard rated line.

An empty seller `cbc:CompanyID` got past this rule when tried and was reported by `PEPPOL-EN16931-R008` instead.

Nothing here checks that the buyer is outside the EU. The same export with the buyer country changed to `DE` passed every layer when tried; whether `G` is right is for your tax determination.

| Term | Meaning | UBL element |
|---|---|---|
| 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-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:

- The seller VAT identifier is written only when VAT is charged, and an export carries a tax amount of zero.
- The seller registration is sent under a tax scheme code other than `VAT`.
- The company registration number is the only seller identifier mapped. That satisfies `BR-CO-26` but not this rule.
- The seller uses a tax representative, and `cac:TaxRepresentativeParty` goes out without its `cac:PartyTaxScheme`.

## How to fix it

1. Take the VAT registration number of the legal entity issuing the invoice from its company settings, in full with the country prefix.
2. Emit it under `cac:AccountingSupplierParty/cac:Party` as `cac:PartyTaxScheme` with `cbc:CompanyID` and `cac:TaxScheme/cbc:ID` of `VAT`, between `cac:PostalAddress` and `cac:PartyLegalEntity`.
3. Where a tax representative accounts for VAT on behalf of the seller, send `cac:TaxRepresentativeParty` with its name, postal address and its own `VAT` `cac:PartyTaxScheme` instead.
4. If the seller has no VAT registration at all, take the question to whoever owns tax determination rather than changing the category in the mapping.

## 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 seller has a legal registration identifier and no VAT identifier

```xml
<cac:AccountingSupplierParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
    <!-- postal address in London, GB, omitted from this fragment -->
    <cac:PartyLegalEntity>
      <cbc:RegistrationName>Example Supplier Ltd</cbc:RegistrationName>
      <cbc:CompanyID>12345678</cbc:CompanyID>
    </cac:PartyLegalEntity>
  </cac:Party>
</cac:AccountingSupplierParty>
```

Fragment of the corrected invoice: the seller VAT identifier under the VAT scheme

```xml
<cac:AccountingSupplierParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
    <!-- 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>
    <cac:PartyLegalEntity>
      <cbc:RegistrationName>Example Supplier Ltd</cbc:RegistrationName>
      <cbc:CompanyID>12345678</cbc:CompanyID>
    </cac:PartyLegalEntity>
  </cac:Party>
</cac:AccountingSupplierParty>
```

The corrected invoice gives the seller a `cac:PartyTaxScheme` with `GB123456789` under the `VAT` scheme; the failing invoice has none. The buyer in New York has no VAT identifier in either document. The failing document reports only `BR-G-02`, not `BR-CO-26`, because the legal registration identifier still identifies the seller.

### What the validator reported

- The failing invoice reports **BR-G-02**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/BR-G-02-invalid.xml)
  - [Download the corrected XML](https://ironfang.uk/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`. A credit note built from the failing invoice gave the same finding when tried.
- Category `G` has its own reason rule, `BR-G-10`, which reported when the recorded export lost its `VATEX-EU-G` code and text. That code on a breakdown of another category is rejected by `PEPPOL-EN16931-P0104`.
- Removing the legal registration identifier too brought `BR-CO-26` beside this rule when tried, since the seller then had no identifier of any kind.

## Related rules

- [BR-IC-02 asks for the buyer VAT identifier as well when the line is an intra-community supply](https://ironfang.uk/docs/finance/rules/BR-IC-02.md)
- [BR-S-02 is the Standard rated seller check, which accepts a tax registration under any scheme](https://ironfang.uk/docs/finance/rules/BR-S-02.md)
- [BR-CO-26 requires some seller identifier on every document, VAT or not](https://ironfang.uk/docs/finance/rules/BR-CO-26.md)
- [BR-CO-09 checks the country prefix of the seller VAT identifier you add](https://ironfang.uk/docs/finance/rules/BR-CO-09.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-24.1: source checked 2026-09-24, explanation last updated 2026-09-24.

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