Skip to content

BR-S-02: Add the seller VAT identifier when lines are Standard rated

A document with a Standard rated line must identify the seller for VAT, through the seller's own tax identifier or a tax representative's VAT identifier.

EN 16931Fatal: the document is invalidVATParties and addresses

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.

TermMeaningUBL element
BT-31Seller VAT identifiercac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID (tax scheme VAT)
BT-32Seller tax registration identifiercac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID (a tax scheme other than VAT)
BT-63Seller tax representative VAT identifiercac:TaxRepresentativeParty/cac:PartyTaxScheme/cbc:CompanyID
BT-151Invoiced item VAT category codecac: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:CompanyID or cac:PartyIdentification/cbc:ID, where it does not count as a VAT identifier.
  • A seller that trades through a tax representative sends cac:TaxRepresentativeParty without its cac:PartyTaxScheme.
  • The serialiser drops the whole cac:PartyTaxScheme when the VAT number field is empty, so a gap in master data reaches the document silently.

How to fix it

  1. Read the seller's VAT registration number, with its country prefix, from the seller's company record. In the recorded example it is GB123456789.
  2. Write it to cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID and give that cac:PartyTaxScheme a cac:TaxScheme/cbc:ID of VAT.
  3. Keep the UBL order inside cac:Party: cac:PartyTaxScheme comes after cac:PostalAddress and before cac:PartyLegalEntity. Placed after cac:PartyLegalEntity, it made the XSD layer fail when tried, and the EN 16931 and Peppol layers were skipped.
  4. If the seller is represented for VAT, send cac:TaxRepresentativeParty with the representative's name, postal address and cac:PartyTaxScheme/cbc:CompanyID under the VAT scheme.
  5. 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

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 with a Standard rated cac:CreditNoteLine and 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-02 for Zero rated lines, BR-E-02 for exempt lines and BR-AE-02 for reverse charge. One seller VAT identifier satisfies all of them.
  • The format of the number is not examined here. BR-CO-09 checks that a VAT identifier begins with a country prefix.

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.