# BR-E-03: Identify the seller for tax when a document-level allowance is exempt

An exempt document-level allowance obliges the document to carry a seller tax identifier or a tax representative VAT identifier.

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

## The short answer

`BR-E-03` fails when the document has an allowance whose `cac:TaxCategory/cbc:ID` is `E` and the seller has neither a `cac:PartyTaxScheme/cbc:CompanyID` nor a tax representative VAT identifier. The correction belongs on the seller party, not on the allowance: add the seller VAT number, `GB123456789` in the recorded example, or another tax registration number of the seller.

When the lines are exempt as well, `BR-E-02` fails beside this rule for the same missing identifier, and adding it clears both findings.

## What the rule checks

Any `cac:AllowanceCharge` with `cbc:ChargeIndicator` of `false` and a `cac:TaxCategory` of `E` under the `VAT` scheme starts the rule, wherever it sits. When tried, an allowance inside an exempt line carrying its own category `E` triggered this rule too, together with the `UBL-CR-558` warning that a line allowance should have no tax category.

The seller passes with a `cbc:CompanyID` in its own `cac:PartyTaxScheme`, whatever the scheme, or through a tax representative identifier under `VAT`. When tried, the discount invoice passed with the seller scheme set to `TAX`, and passed with the seller tax scheme replaced by a representative; with the representative's scheme also set to `TAX`, it reported this rule, `BR-E-02` and `BR-56`.

The category of the lines decides which rule joins this one. With the exempt line of the recorded example it is `BR-E-02`; when tried with a Standard rated line and an exempt discount, the missing seller identifier brought `BR-S-02` instead.

An empty shell does not count. When tried, keeping the seller `cac:PartyTaxScheme` on the discount invoice but removing its `cbc:CompanyID` reported this rule, `BR-E-02` and `UBL-SR-53`.

| Term | Meaning | UBL element |
|---|---|---|
| BT-31 | Seller VAT identifier | `cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID (tax scheme VAT)` |
| BT-32 | Seller tax registration identifier | `cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID (a tax scheme other than VAT)` |
| BT-63 | Seller tax representative VAT identifier | `cac:TaxRepresentativeParty/cac:PartyTaxScheme/cbc:CompanyID` |
| BT-95 | Document level allowance VAT category code | `cac:AllowanceCharge[cbc:ChargeIndicator = false]/cac:TaxCategory/cbc:ID` |

## How an integration ends up here

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

- The document discount is created in category `E` to match the lines it reduces, while the seller party comes from a routine that adds a tax scheme only for documents that charge VAT.
- The seller VAT number is on record but dropped whenever the document shows 0.00 of VAT.
- A seller with only exempt supplies has no VAT number, and its national tax number is not mapped.
- The seller identifier was put in `cac:PartyIdentification` or `cac:PartyLegalEntity` instead of `cac:PartyTaxScheme`.

## How to fix it

1. Leave the allowance alone: category `E` at 0 is right for a discount on exempt supplies, and the finding is not about it.
2. Add the seller tax identifier in `cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID`, under `VAT` for a VAT number or under another scheme for a national tax number, between `cac:PostalAddress` and `cac:PartyLegalEntity`.
3. If the seller is represented for VAT, send `cac:TaxRepresentativeParty` with the representative's VAT identifier instead.
4. Make the seller tax identifier part of every document the seller issues, not only those with VAT to charge, so that exempt lines, allowances and charges are covered alike.

## 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 party with no PartyTaxScheme, and an exempt discount of 5.00

```xml
<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>

<cac:AllowanceCharge>
  <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
  <cbc:AllowanceChargeReasonCode>95</cbc:AllowanceChargeReasonCode>
  <cbc:AllowanceChargeReason>Discount</cbc:AllowanceChargeReason>
  <cbc:Amount currencyID="GBP">5.00</cbc:Amount>
  <cac:TaxCategory>
    <cbc:ID>E</cbc:ID>
    <cbc:Percent>0</cbc:Percent>
    <cac:TaxScheme>
      <cbc:ID>VAT</cbc:ID>
    </cac:TaxScheme>
  </cac:TaxCategory>
</cac:AllowanceCharge>
```

Fragment of the corrected invoice: the seller VAT identifier is back, and the discount is unchanged

```xml
<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>

<!-- the exempt discount of 5.00 is the same as in the failing invoice -->
```

The corrected invoice gives the seller a `cac:PartyTaxScheme` holding `GB123456789` under the `VAT` scheme, and the failing one has none; the exempt discount of 5.00 and the exempt breakdown of 20.00 are the same in both. The failing document also reports `BR-E-02`, because its only line is exempt and meets the same missing identifier. Adding the seller tax scheme clears both findings.

### What the validator reported

- The failing invoice reports [BR-E-02](https://ironfang.com/docs/finance/rules/BR-E-02.md) and **BR-E-03**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.com/finance/rule-examples/BR-E-03-invalid.xml)
  - [Download the corrected XML](https://ironfang.com/finance/rule-examples/exempt-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`. An exempt credit note with the same discount and no seller tax scheme reported this rule and `BR-E-02` when tried.
- Reported by the EN 16931 layer as one fatal finding at the document root, however many exempt allowances there are.
- Charges have the parallel rule `BR-E-04`. A Standard rated allowance falls under `BR-S-03`, and a reverse-charge allowance under `BR-AE-03`, which asks for a buyer identifier as well.

## Related rules

- [BR-E-02 is reported beside this rule when the lines are exempt too](https://ironfang.com/docs/finance/rules/BR-E-02.md)
- [BR-E-06 requires the exempt allowance to carry a VAT rate of 0](https://ironfang.com/docs/finance/rules/BR-E-06.md)
- [BR-S-03 asks for the seller identifier when a document-level allowance is Standard rated](https://ironfang.com/docs/finance/rules/BR-S-03.md)
- [BR-AE-03 is the reverse-charge allowance rule, which also needs a buyer identifier](https://ironfang.com/docs/finance/rules/BR-AE-03.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-E-03](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-E-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-E-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
