# BR-S-04: Add a seller VAT identifier when a document charge is Standard rated
A document-level charge in VAT category `S`, such as freight, requires 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-S-04/
- Explanation last updated: 2026-09-28
## The short answer
`BR-S-04` fails when a `cac:AllowanceCharge` flagged as a charge has a `cac:TaxCategory` of `S` under the `VAT` scheme, and the document gives neither a seller tax identifier, under any scheme, nor a tax representative VAT identifier. Add the seller's VAT number in a `cac:PartyTaxScheme` of the seller party or, when the seller is represented for VAT, the representative's number in `cac:TaxRepresentativeParty`.
Charging Standard rated VAT on freight or packing presupposes a VAT registered seller. The validator only asks that the registration be stated where it can see it.
## What the rule checks
Any charge with `cbc:ChargeIndicator` of `true` and a Standard rated category under the `VAT` scheme brings the rule into play. The seller condition is met by any `cbc:CompanyID` in a seller `cac:PartyTaxScheme`, or by a tax representative `cbc:CompanyID` whose tax scheme is `VAT`.
The tax representative route works on its own. When tried, the freight invoice without a seller `cac:PartyTaxScheme` but with a `cac:TaxRepresentativeParty` holding `GB987654321` under `VAT` passed every layer.
The representative's scheme is checked. Changed to `GST`, the same invoice reported this rule and `BR-S-02` again, plus `BR-56` because the representative then had no VAT identifier.
The finding is per document, not per charge. When tried, adding a second Standard rated charge, for packing, to the failing invoice still produced a single `BR-S-04`, reported at the root element.
| Term | Meaning | UBL element |
|---|---|---|
| BT-102 | Document level charge VAT category code | `cac:AllowanceCharge[cbc:ChargeIndicator = true]/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:
- Freight is added by a shipping or carrier module that applies the Standard rated tax code automatically, while the seller party comes from a record without a VAT number.
- The export includes `cac:PartyTaxScheme` in the seller party only for some document types, and this document was produced along a different route.
- The seller's VAT number is stored per branch or per country, and the branch that raised the document has none.
- A tax representative is used, and its VAT number is sent under a local tax scheme name instead of `VAT`.
## How to fix it
1. Establish whether the seller is VAT registered for the supply. If so, take the number, with its country prefix, from the seller record: `GB123456789` in the recorded example.
2. Write it into the seller party as `cac:PartyTaxScheme/cbc:CompanyID` with `cac:TaxScheme/cbc:ID` of `VAT`, between `cac:PostalAddress` and `cac:PartyLegalEntity`.
3. Where a tax representative accounts for the VAT, give `cac:TaxRepresentativeParty` a `cac:PartyTaxScheme` with the representative's number under the `VAT` scheme.
4. If there is no registration to state, the Standard rated category on the charge and on the lines is what needs reviewing, with whoever owns the tax setup, before anything in the XML changes.
## 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 freight charge, and a seller party with no PartyTaxScheme
```xml
7300010000001
Example Supplier Ltd
12345678
true
FC
Freight
7.50
S
20
VAT
```
Fragment of the corrected invoice: the seller PartyTaxScheme with its VAT number
```xml
7300010000001
GB123456789
VAT
Example Supplier Ltd
12345678
```
The corrected invoice has a seller `cac:PartyTaxScheme` with `GB123456789` under the `VAT` scheme, which is missing from the failing invoice; nothing else differs. `BR-S-02` is reported as well, because the invoice line is Standard rated at 20 and needs the same identifier. The freight charge of 7.50 and the breakdown of 32.50 taxable and 6.50 VAT are unchanged between the two.
### What the validator reported
- The failing invoice reports [BR-S-02](https://ironfang.com/docs/finance/rules/BR-S-02.md) and **BR-S-04**. The corrected document passes every layer with no findings.
- [Download the failing XML](https://ironfang.com/finance/rule-examples/BR-S-04-invalid.xml)
- [Download the corrected XML](https://ironfang.com/finance/rule-examples/standard-rated-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`. The credit note version of the recorded example reported `BR-S-02` and `BR-S-04` when tried.
- Reported by the EN 16931 layer as a fatal finding at the root of the document.
- Allowances have their own version, `BR-S-03`, and Zero rated charges theirs, `BR-Z-04`. One seller VAT identifier satisfies every one of these rules.
- The number itself is not validated here; `BR-CO-09` checks its country prefix.
## Related rules
- [BR-S-03 asks the same of a Standard rated document-level allowance](https://ironfang.com/docs/finance/rules/BR-S-03.md)
- [BR-S-07 requires a Standard rated charge to carry a rate above zero](https://ironfang.com/docs/finance/rules/BR-S-07.md)
- [BR-56 requires a tax representative to carry a VAT identifier of its own](https://ironfang.com/docs/finance/rules/BR-56.md)
- [BR-Z-04 is the Zero rated version of this charge rule](https://ironfang.com/docs/finance/rules/BR-Z-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-S-04](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-S-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-S-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