# BR-E-02: Add a seller tax identifier to an invoice with exempt lines
A document with a line in the exempt category `E` must carry a seller tax identifier, or the VAT identifier of a seller tax representative.
- 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-E-02/
- Explanation last updated: 2026-09-28
## The short answer
`BR-E-02` fails when a line has VAT category `E` and the seller party has no `cac:PartyTaxScheme/cbc:CompanyID`, with no tax representative VAT identifier to stand in for it. Give the seller its tax identifier in `cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID`: in the recorded example that is the VAT number `GB123456789` under the `VAT` scheme.
An exempt supply does not excuse the seller from identifying itself for tax. A seller whose supplies are all exempt may have no VAT number to give, and the seller tax registration identifier (BT-32), a national tax number sent under a scheme other than `VAT`, satisfies the rule just as well.
## What the rule checks
Only exempt lines start this rule. It looks for a `cac:ClassifiedTaxCategory` with `cbc:ID` of `E` under the `VAT` scheme, an element that exists only in `cac:Item`; exempt document-level allowances and charges are left to `BR-E-03` and `BR-E-04`, which test the seller in the same way.
A seller `cbc:CompanyID` under any tax scheme passes. When tried, the exempt invoice with the seller scheme changed from `VAT` to `TAX` validated with no findings.
The only alternative to the seller's own tax scheme is a tax representative with a `cbc:CompanyID` under `VAT`. When tried, adding a representative holding `GB987654321` to the failing exempt invoice made it valid.
The number must sit in the tax scheme element. When tried, writing `GB123456789` into the seller `cac:PartyLegalEntity/cbc:CompanyID` in place of `12345678` still failed this rule, and so did sending it as `cac:PartyIdentification/cbc:ID`.
Presence is all that is tested. With an empty seller `cbc:CompanyID` this rule passed when tried and `PEPPOL-EN16931-R008` reported the empty element; with `cbc:CompanyID` removed and the `cac:PartyTaxScheme` kept, the rule failed together with `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-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)` |
## How an integration ends up here
Possible causes, from the shape of the rule rather than from measured usage:
- The seller record has no VAT number because the business makes only exempt supplies, and the export writes nothing in its place.
- The export adds the seller `cac:PartyTaxScheme` only when the document charges VAT, and an exempt invoice charges none.
- The seller VAT number is mapped to `cac:PartyLegalEntity/cbc:CompanyID` or `cac:PartyIdentification/cbc:ID`, neither of which this rule reads.
- A national tax number is held for the seller but never mapped, because only the VAT number field was wired to the XML.
## How to fix it
1. Establish which tax identifier the seller has: a VAT number, a national tax registration number, or a tax representative with a VAT number.
2. Write a VAT number, with its country prefix, to `cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID` with `cac:TaxScheme/cbc:ID` of `VAT`, after `cac:PostalAddress` and before `cac:PartyLegalEntity`.
3. Write a tax registration number that is not a VAT number the same way, in a `cac:PartyTaxScheme` whose `cac:TaxScheme/cbc:ID` is something other than `VAT`, such as `TAX`. The seller may have one tax scheme of each kind, so both can be sent side by side.
4. For a seller represented for VAT, send `cac:TaxRepresentativeParty` with the representative's name, postal address and VAT identifier.
5. If the seller has none of these, take it to whoever owns the tax setup before issuing the invoice: without one, a document with exempt lines cannot pass this rule.
## Before and after
These are fragments, not complete documents. The complete synthetic documents they come from are linked below.
Fragment of the failing invoice: an exempt line, and a seller party with no PartyTaxScheme
```xml
7300010000001
Example Supplier Ltd
12345678
E
0
VAT
```
Fragment of the corrected invoice: the seller VAT identifier between the postal address and the legal entity
```xml
7300010000001
GB123456789
VAT
Example Supplier Ltd
12345678
```
The corrected invoice has a seller `cac:PartyTaxScheme` holding `GB123456789` under the `VAT` scheme; the failing invoice has no seller tax scheme at all. The failing document reports only `BR-E-02`. Its one exempt line of 25.00 is the only exempt content, so `BR-E-03` and `BR-E-04` have nothing to check, and the seller legal registration identifier `12345678` keeps `BR-CO-26` quiet.
### What the validator reported
- The failing invoice reports **BR-E-02**. The corrected document passes every layer with no findings.
- [Download the failing XML](https://ironfang.com/finance/rule-examples/BR-E-02-invalid.xml)
- [Download the corrected XML](https://ironfang.com/finance/rule-examples/exempt-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 no seller tax scheme reported this rule alone when tried.
- Reported by the EN 16931 layer as one fatal finding at the document root, however many lines are exempt.
- Most VAT categories have a rule of this shape for their lines, such as `BR-S-02` for Standard rated, and one seller identifier satisfies them together. The export and intra-community supply rules, `BR-G-02` and `BR-IC-02`, are stricter and accept only an identifier under the `VAT` scheme.
- Nothing is asked of the buyer here, unlike the reverse-charge rule `BR-AE-02`.
## Related rules
- [BR-E-03 applies the same seller test when an exempt document-level allowance is present](https://ironfang.com/docs/finance/rules/BR-E-03.md)
- [BR-E-04 applies the same seller test when an exempt document-level charge is present](https://ironfang.com/docs/finance/rules/BR-E-04.md)
- [BR-S-02 is the Standard rated version of this requirement](https://ironfang.com/docs/finance/rules/BR-S-02.md)
- [BR-E-05 requires the exempt line itself to carry a VAT rate of 0](https://ironfang.com/docs/finance/rules/BR-E-05.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-02](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-E-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.com/docs/finance/rules/BR-E-02)
- [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