# BR-S-03: Add a seller VAT identifier when a document allowance is Standard rated
A document-level allowance in VAT category `S` requires the seller to be identified for VAT, by its own 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-S-03/
- Explanation last updated: 2026-09-28
## The short answer
`BR-S-03` fails when the document carries an allowance whose `cac:TaxCategory` is `S` under the `VAT` scheme, and the document has neither a seller tax identifier, under any scheme, nor a tax representative VAT identifier. Put the seller's VAT number in `cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID` under the `VAT` scheme: `GB123456789` in the recorded example.
A discount taken off Standard rated supplies reduces the VAT a registered seller charges. The Standard rated line that the loyalty rebate applies to raises `BR-S-02` for the same gap, and one correction clears both.
## What the rule checks
The rule starts from the document root and looks for any `cac:AllowanceCharge` with `cbc:ChargeIndicator` of `false` whose `cac:TaxCategory` has `cbc:ID` of `S` and a `VAT` tax scheme. If one exists, the seller must have a `cac:PartyTaxScheme/cbc:CompanyID`, or `cac:TaxRepresentativeParty` must have one under the `VAT` scheme.
The seller's own tax scheme is not examined. When tried on the rebate invoice, a seller `cac:PartyTaxScheme` carrying `GB123456789` under scheme `TAX` passed every layer, which is how a seller tax registration identifier (BT-32) satisfies the rule.
The search is not limited to document-level allowances. When tried, an allowance inside an invoice line that carried its own `S` category, in a Zero rated invoice with no seller identifier, reported this rule next to `BR-Z-02` and `BR-S-01`, plus the warning `UBL-CR-558` for a category on a line allowance.
Only the presence of `cbc:CompanyID` is tested. An empty seller `cbc:CompanyID` on the rebate invoice cleared both `BR-S-02` and this rule when tried, and the Peppol layer rejected it as `PEPPOL-EN16931-R008` instead.
| 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 (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` |
## How an integration ends up here
Possible causes, from the shape of the rule rather than from measured usage:
- The seller party is built from a company record whose VAT number is empty for this trading entity, so `cac:PartyTaxScheme` is left out.
- The export writes the VAT number into `cac:PartyLegalEntity/cbc:CompanyID` or `cac:PartyIdentification`, neither of which the rule accepts.
- A seller represented for VAT sends `cac:TaxRepresentativeParty` with a name and address but no `cac:PartyTaxScheme`, or with a scheme other than `VAT`.
- A rebate or loyalty credit is booked under a Standard rated tax code by default, even though the seller is not VAT registered and nothing on the document should carry category `S`.
## How to fix it
1. Look up the seller's VAT registration number, with its country prefix, in the seller's company record.
2. Write it to `cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID` with `cac:TaxScheme/cbc:ID` of `VAT`, placing `cac:PartyTaxScheme` after `cac:PostalAddress` and before `cac:PartyLegalEntity`.
3. If the seller is represented for VAT, send the representative's VAT number in `cac:TaxRepresentativeParty/cac:PartyTaxScheme/cbc:CompanyID` under the `VAT` scheme instead.
4. If the seller has no VAT registration at all, a Standard rated allowance is itself wrong. Settle the VAT treatment of the discount, and of the lines it reduces, with whoever owns the tax setup rather than borrowing another identifier.
## 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 Standard rated loyalty rebate, and a seller party with no PartyTaxScheme
```xml
7300010000001
Example Supplier Ltd
12345678
false
100
Loyalty rebate
5.00
S
20
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 none, and nothing else differs. The failing document also reports `BR-S-02`, because its one line is Standard rated at 20 and needs the same identifier. The loyalty rebate of 5.00 and the Standard rated breakdown of 20.00 taxable and 4.00 VAT are identical in both documents.
### What the validator reported
- The failing invoice reports [BR-S-02](https://ironfang.com/docs/finance/rules/BR-S-02.md) and **BR-S-03**. The corrected document passes every layer with no findings.
- [Download the failing XML](https://ironfang.com/finance/rule-examples/BR-S-03-invalid.xml)
- [Download the corrected XML](https://ironfang.com/finance/rule-examples/standard-rated-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 recorded example reported `BR-S-02` and `BR-S-03` when tried.
- Reported by the EN 16931 layer as a fatal finding at the document root.
- Charges have the matching rule `BR-S-04`, and Zero rated allowances `BR-Z-03`. A single seller VAT identifier answers all of them.
- Whether the allowance has a rate above zero is a separate question, answered by `BR-S-06`.
## Related rules
- [BR-S-02 asks for the same seller identifier when a line is Standard rated](https://ironfang.com/docs/finance/rules/BR-S-02.md)
- [BR-S-04 is the counterpart for Standard rated document-level charges](https://ironfang.com/docs/finance/rules/BR-S-04.md)
- [BR-S-06 requires a Standard rated allowance to carry a rate above zero](https://ironfang.com/docs/finance/rules/BR-S-06.md)
- [BR-Z-03 applies the same requirement to Zero rated document-level allowances](https://ironfang.com/docs/finance/rules/BR-Z-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-S-03](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-S-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-S-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