# BR-E-04: Put the seller tax identifier in PartyTaxScheme when a document-level charge is exempt

A document-level charge in category `E` needs the seller tax identifier in the seller PartyTaxScheme, 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-04/
- Explanation last updated: 2026-09-28

## The short answer

`BR-E-04` fails when a charge, an `cac:AllowanceCharge` with `cbc:ChargeIndicator` of `true`, has a `cac:TaxCategory` of `E` and the document gives no seller tax identifier. In the recorded example the seller VAT number `GB123456789` was sent as `cac:PartyIdentification/cbc:ID`, where no VAT rule looks for it; move it into `cac:PartyTaxScheme/cbc:CompanyID` under the `VAT` scheme.

This is a mapping slip rather than missing data, so the fix is a move. `BR-E-02` fails alongside for the exempt line and clears with the same move.

## What the rule checks

The rule is started by a charge whose `cac:TaxCategory` has `cbc:ID` of `E` under the `VAT` scheme. The amount and reason of the charge play no part; the 2.50 administration fee of the recorded example is only what makes the rule apply.

The seller is identified by a `cbc:CompanyID` in its own `cac:PartyTaxScheme`, under any scheme, or by a tax representative `cbc:CompanyID` under `VAT`. When tried, the fee invoice was valid with the seller scheme set to `TAX`, and valid with the seller tax scheme replaced by a representative holding a VAT identifier.

A seller identifier in `cac:PartyIdentification/cbc:ID` is ignored by this rule even when it is a VAT number, as the recorded example shows. It does count as a seller identifier for `BR-CO-26`, which the legal registration identifier `12345678` satisfies here anyway.

The companion finding comes from the line category. With the exempt line of the recorded example it is `BR-E-02`; when tried with a Standard rated line of 25.00 beside the exempt fee and no seller tax scheme, `BR-S-02` was reported with this rule instead.

| 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-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 seller VAT number is mapped to the party identifier because an earlier format or integration expected it there.
- An administration or handling fee inherits category `E` from an exempt contract, while the seller party is built from a template without a tax scheme.
- The seller tax scheme block is written only when the invoice total includes VAT.
- The seller is represented for VAT, but `cac:TaxRepresentativeParty` is sent without its `cac:PartyTaxScheme`.

## How to fix it

1. Write the seller VAT number to `cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID` with `cac:TaxScheme/cbc:ID` of `VAT`, after `cac:PostalAddress` and before `cac:PartyLegalEntity`.
2. Decide whether `cac:PartyIdentification` should stay. It carries the seller identifier (BT-29), which comes before `cac:PostalAddress`; keep it only if the seller really is identified that way. The corrected invoice drops it.
3. Keep the charge in category `E` at 0 if the fee shares the exemption of the service; neither its category nor its rate is at issue here.
4. Change the mapping so that the VAT number always lands in the tax scheme, whatever else the seller party carries.

## 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 VAT number sent as a party identifier, and an exempt administration fee

```xml
<cac:AccountingSupplierParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
    <cac:PartyIdentification>
      <cbc:ID>GB123456789</cbc:ID>
    </cac:PartyIdentification>
    <!-- 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>true</cbc:ChargeIndicator>
  <cbc:AllowanceChargeReason>Administration fee</cbc:AllowanceChargeReason>
  <cbc:Amount currencyID="GBP">2.50</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 same number in the seller PartyTaxScheme, and no party identification

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

In the failing invoice `GB123456789` is the seller `cac:PartyIdentification/cbc:ID` and the seller has no `cac:PartyTaxScheme`; the corrected invoice has no party identification and carries the same number in a `cac:PartyTaxScheme` under `VAT`. The failing document also reports `BR-E-02`, since its exempt line of 25.00 depends on the same seller identifier. The administration fee of 2.50 and the exempt breakdown of 27.50 are unchanged.

### What the validator reported

- The failing invoice reports [BR-E-02](https://ironfang.com/docs/finance/rules/BR-E-02.md) and **BR-E-04**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.com/finance/rule-examples/BR-E-04-invalid.xml)
  - [Download the corrected XML](https://ironfang.com/finance/rule-examples/exempt-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`. An exempt credit note with the fee and no seller tax scheme reported this rule and `BR-E-02` when tried.
- Reported by the EN 16931 layer at the document root, once for the document however many exempt charges it has.
- Allowances have the parallel rule `BR-E-03`. Standard rated charges come under `BR-S-04`, and reverse-charge charges under `BR-AE-04`, which adds a buyer condition.

## Related rules

- [BR-E-02 fails beside this rule when the lines of the document are exempt as well](https://ironfang.com/docs/finance/rules/BR-E-02.md)
- [BR-E-07 requires the exempt charge to carry a VAT rate of 0](https://ironfang.com/docs/finance/rules/BR-E-07.md)
- [BR-S-04 asks for the seller identifier when a document-level charge is Standard rated](https://ironfang.com/docs/finance/rules/BR-S-04.md)
- [BR-AE-04 is the reverse-charge charge rule, with a buyer condition added](https://ironfang.com/docs/finance/rules/BR-AE-04.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-04](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-E-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-E-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
