The short answer
BR-S-02 fails when a line has VAT category S but the seller party has no cac:PartyTaxScheme/cbc:CompanyID and no tax representative VAT identifier is given either. Add the seller's VAT registration number in cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID, with cac:TaxScheme/cbc:ID set to VAT.
Use the seller's real registration. If the seller has no VAT number of its own, the answer is either its tax representative or a second look at whether Standard rated VAT belongs on the invoice at all.
What the rule checks
The rule is triggered by a cac:ClassifiedTaxCategory with cbc:ID of S under the VAT scheme, which is the category of a line item. Document-level allowances and charges are left to other rules: when tried, a Standard rated document charge with no seller VAT identifier was reported as BR-S-04, and a Standard rated document allowance as BR-S-03, not as this rule.
On the seller side, a cbc:CompanyID in any cac:PartyTaxScheme of the seller party is enough, whatever tax scheme that element names. That is how the seller tax registration identifier (BT-32) qualifies. When tried, a seller cac:PartyTaxScheme with scheme TAX in place of VAT passed this rule and every other layer.
The other way to pass is cac:TaxRepresentativeParty/cac:PartyTaxScheme/cbc:CompanyID, and there the scheme must be VAT. When tried, a valid invoice with a tax representative still validated after the seller identifier was removed; with the representative's scheme also changed to TAX, it reported this rule and BR-56.
The seller legal registration identifier in cac:PartyLegalEntity/cbc:CompanyID plays no part. The failing invoice keeps its 12345678 there and still fails.
Only the presence of the element is tested. An empty seller cbc:CompanyID got past this rule when tried and was reported by PEPPOL-EN16931-R008 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-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 VAT number lives in company settings that the export does not read, or it is blank for one legal entity or one environment.
- The seller party is built from the same template as the buyer party, which has no
cac:PartyTaxScheme. - The VAT number is written to
cac:PartyLegalEntity/cbc:CompanyIDorcac:PartyIdentification/cbc:ID, where it does not count as a VAT identifier. - A seller that trades through a tax representative sends
cac:TaxRepresentativePartywithout itscac:PartyTaxScheme. - The serialiser drops the whole
cac:PartyTaxSchemewhen the VAT number field is empty, so a gap in master data reaches the document silently.
How to fix it
- Read the seller's VAT registration number, with its country prefix, from the seller's company record. In the recorded example it is
GB123456789. - Write it to
cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyIDand give thatcac:PartyTaxSchemeacac:TaxScheme/cbc:IDofVAT. - Keep the UBL order inside
cac:Party:cac:PartyTaxSchemecomes aftercac:PostalAddressand beforecac:PartyLegalEntity. Placed aftercac:PartyLegalEntity, it made the XSD layer fail when tried, and the EN 16931 and Peppol layers were skipped. - If the seller is represented for VAT, send
cac:TaxRepresentativePartywith the representative's name, postal address andcac:PartyTaxScheme/cbc:CompanyIDunder theVATscheme. - If there is neither a seller VAT number nor a representative, do not borrow another identifier to fill the gap. Settle with whoever owns the tax setup whether the lines should carry Standard rated VAT.
Validate your corrected invoice
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 line, and a seller party with no PartyTaxScheme
<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:InvoiceLine>
<cbc:ID>1</cbc:ID>
<!-- quantity and line amount omitted from this fragment -->
<cac:Item>
<cbc:Name>Example service</cbc:Name>
<cac:ClassifiedTaxCategory>
<cbc:ID>S</cbc:ID>
<cbc:Percent>20</cbc:Percent>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:ClassifiedTaxCategory>
</cac:Item>
<!-- price omitted from this fragment -->
</cac:InvoiceLine>Fragment of the corrected invoice: the seller VAT identifier between the postal address and the legal entity
<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 corrected invoice has a seller cac:PartyTaxScheme holding GB123456789 under the VAT scheme, and the failing one has no cac:PartyTaxScheme in the seller party. The failing document reports only BR-S-02. BR-CO-26 stays quiet because the seller legal registration identifier is still there; with that removed as well, BR-CO-26 was reported too.
What the validator reported
- The failing invoice reports BR-S-02. The corrected document passes every layer with no findings.Download the failing XMLDownload the corrected 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
InvoiceandCreditNote. A credit note with a Standard ratedcac:CreditNoteLineand no seller identifier reported the same rule when tried. - The EN 16931 layer reports it as a fatal finding at the document root, once per document however many lines are Standard rated.
- The other categories have their own versions of this requirement, such as
BR-Z-02for Zero rated lines,BR-E-02for exempt lines andBR-AE-02for reverse charge. One seller VAT identifier satisfies all of them. - The format of the number is not examined here.
BR-CO-09checks that a VAT identifier begins with a country prefix.
Related rules
- BR-CO-09 checks the country prefix on the seller VAT identifier this rule asks for
- BR-56 requires a tax representative, when one is sent, to carry its own VAT identifier
- BR-AE-02 is the reverse-charge counterpart, which also needs a buyer identifier
- BR-CO-26 joins this rule when the seller has no legal registration identifier either
- Browse every rule in the reference
- Background: Understanding EN 16931 validation errors
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-24.1: source checked 2026-09-24, explanation last updated 2026-09-24.
The official definition of BR-S-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.
