# BR-G-03: Add the seller VAT identifier to an export invoice with an allowance in category G

A document-level allowance in category `G` needs a seller VAT identifier, or a tax representative one, under the `VAT` scheme, as an export line does.

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

## The short answer

`BR-G-03` fails when a `cac:AllowanceCharge` with `cbc:ChargeIndicator` of `false` is in category `G` and there is no VAT identifier for the seller or its tax representative. The recorded export has a volume discount of 2.50 in `G` and no seller `cac:PartyTaxScheme`; adding `GB123456789` under the `VAT` scheme clears it.

The same gap is reported for the export line by `BR-G-02`, so on an ordinary export invoice the two findings arrive together, and one identifier fixes both.

## What the rule checks

The allowance is the trigger, not the lines. When tried, a Standard rated invoice with a `G` discount of 2.50, whose seller was registered only under the scheme `TAX`, reported this rule alone; `BR-S-02` accepted that registration for the Standard rated line. An allowance inside a line counts as well: when tried, an allowance of 0.00 in `G` placed in the Standard rated line, again with the seller only under `TAX`, reported this rule and the warning `UBL-CR-558`.

To pass, the seller needs a `cbc:CompanyID` in a `cac:PartyTaxScheme` under `cac:AccountingSupplierParty/cac:Party` whose tax scheme is `VAT`, or `cac:TaxRepresentativeParty` needs the same. When tried, a tax representative with a name, a London address and `GB987654321` under `VAT` made the discounted export valid with no seller VAT identifier.

A registration under `TAX` is not a VAT identifier here. When tried, the discounted export with its seller `cac:PartyTaxScheme` switched from `VAT` to `TAX` reported this rule and `BR-G-02`, exactly as with the identifier removed.

Only the seller side is read, and the buyer in New York has no VAT identifier in either document. The finding is raised once, at the document root.

| Term | Meaning | UBL element |
|---|---|---|
| BT-95 | Document level allowance VAT category code | `cac:AllowanceCharge[cbc:ChargeIndicator = false]/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:

- The seller VAT section is emitted only when the document carries VAT, and everything on an export is at a rate of 0.
- The discount is added by a pricing module after the header is built, and the header came from a profile that leaves out the seller tax section for buyers outside the EU.
- The seller registration is sent under a generic tax scheme code such as `TAX`.
- The allowance takes category `G` from the export lines while the seller party comes from a template meant for sellers without a VAT registration.

## How to fix it

1. Take the VAT number of the legal entity issuing the invoice, with its country prefix, from its company settings.
2. Emit it as `cac:PartyTaxScheme` in the seller party, after `cac:PostalAddress` and before `cac:PartyLegalEntity`, with `cac:TaxScheme/cbc:ID` of `VAT`.
3. Where a tax representative handles VAT for the seller, send `cac:TaxRepresentativeParty` with its name, postal address and its own `VAT` registration instead.
4. Leave the allowance in `G` with a rate of `0`, like the export lines it discounts; the category is not what this rule is about.

## 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 discount in category G, and a seller with 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>
<!-- buyer in New York, US, omitted from this fragment -->
<cac:AllowanceCharge>
  <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
  <cbc:AllowanceChargeReasonCode>95</cbc:AllowanceChargeReasonCode>
  <cbc:AllowanceChargeReason>Volume discount</cbc:AllowanceChargeReason>
  <cbc:Amount currencyID="GBP">2.50</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 seller VAT identifier under the VAT scheme, with the same discount

```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>
<!-- buyer and the discount of 2.50 in G omitted from this fragment -->
```

The corrected invoice gives the seller `GB123456789` in a `cac:PartyTaxScheme` under `VAT`; the failing invoice has no seller VAT identifier, and the discount of 2.50 in `G` is the same in both. The failing document also reports `BR-G-02`, because its line is in `G` too and needs the same 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-03**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.com/finance/rule-examples/BR-G-03-invalid.xml)
  - [Download the corrected XML](https://ironfang.com/finance/rule-examples/export-allowance-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 reported `BR-G-02` and this rule when tried.
- Document-level charges in `G` have the identical requirement under `BR-G-04`, and the allowance itself must have a rate of 0 under `BR-G-06`.
- Nothing here compares countries. The rule takes category `G` as given; whether the goods really leave the EU is for your tax determination.

## Related rules

- [BR-G-02 makes the same demand for export lines and is reported beside this rule](https://ironfang.com/docs/finance/rules/BR-G-02.md)
- [BR-G-04 is the matching check for a document-level charge in category G](https://ironfang.com/docs/finance/rules/BR-G-04.md)
- [BR-G-06 requires the G allowance itself to have a rate of 0](https://ironfang.com/docs/finance/rules/BR-G-06.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-03](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-G-03/) 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-03)
- [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