# UBL-SR-53: Add the CompanyID to a PartyTaxScheme, or remove the scheme

Every `cac:PartyTaxScheme` must hold both a `cbc:CompanyID` and a `cac:TaxScheme/cbc:ID`. A tax scheme sent without the number it registers is rejected.

- Layer: EN 16931
- Severity: fatal (the document is invalid)
- Topics: Parties and addresses, VAT
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/UBL-SR-53/
- Explanation last updated: 2026-09-24

## The short answer

`UBL-SR-53` fails when a `cac:PartyTaxScheme` is missing either its `cbc:CompanyID` or its `cac:TaxScheme/cbc:ID`. In the recorded example the seller block names the `VAT` scheme but carries no VAT number. Put the party's identifier for that scheme in `cbc:CompanyID`, or, if the party has no such registration, remove the whole `cac:PartyTaxScheme`.

Removing the block is right only when the registration genuinely does not exist. For the seller, the VAT category rules then decide whether the invoice can go without a VAT identifier; with a standard rated line it cannot, and `BR-S-02` says so.

## What the rule checks

The rule runs on each `cac:PartyTaxScheme` in the document, for the seller, the buyer and the tax representative alike, and the finding is located at that block. When tried, a buyer block holding only the `VAT` scheme reported `UBL-SR-53` alone.

Both children must exist, whatever the scheme. The tax scheme value is not examined, so a block for a non-VAT tax registration needs its `cbc:CompanyID` too.

The number is not read, only looked for. When tried, an empty `cbc:CompanyID` passed this rule and was reported by `PEPPOL-EN16931-R008` instead.

The two halves are enforced at different layers. The UBL schema requires `cac:TaxScheme` itself, so a block without it failed the XSD layer when tried; a `cac:TaxScheme` with `cbc:Name` in place of `cbc:ID` reached this rule and was reported, with the warning `UBL-CR-174` for the name.

| Term | Meaning | UBL element |
|---|---|---|
| BT-31 | Seller VAT identifier | `cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID` |
| BT-48 | Buyer VAT identifier | `cac:AccountingCustomerParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID` |
| BT-63 | Seller tax representative VAT identifier | `cac:TaxRepresentativeParty/cac:PartyTaxScheme/cbc:CompanyID` |
| - | Tax scheme identifier of any party tax scheme | `cac:PartyTaxScheme/cac:TaxScheme/cbc:ID` |

## How an integration ends up here

Possible causes, from the shape of the rule rather than from measured usage:

- The serialiser writes the tax scheme block for every party and fills `cbc:CompanyID` only when a VAT number is on record, so parties without one get a block holding the scheme alone.
- The VAT number is held in a field the mapping does not read for this party type.
- A null VAT number is dropped as an empty element, but its parent block is still written.
- A block meant for a non-VAT tax registration has its scheme filled and its number left out.

## How to fix it

1. Use the finding location to see which party the block belongs to.
2. If the party is registered under that scheme, take the identifier from the party record and write it as `cbc:CompanyID`, before `cac:TaxScheme`. For VAT, include the country prefix, which `BR-CO-09` checks.
3. If the party has no registration under that scheme, write no `cac:PartyTaxScheme` for it. Do not put another number, such as a company registration number, in its place.
4. For the seller, re-check the VAT category rules after the change: a standard rated line needs a seller VAT or tax registration identifier, or a tax representative VAT identifier, and `BR-S-02` reports its absence.

## Before and after

These are fragments, not complete documents. The complete synthetic documents they come from are linked below.

Fragment of the failing invoice: the seller tax scheme names VAT and gives no number

```xml
<cac:AccountingSupplierParty>
  <cac:Party>
    <!-- endpoint and postal address omitted from this fragment -->
    <cac:PartyTaxScheme>
      <cac:TaxScheme>
        <cbc:ID>VAT</cbc:ID>
      </cac:TaxScheme>
    </cac:PartyTaxScheme>
    <!-- legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingSupplierParty>
```

Fragment of the corrected invoice: the seller VAT number comes before the tax scheme

```xml
<cac:AccountingSupplierParty>
  <cac:Party>
    <!-- endpoint and postal address omitted from this fragment -->
    <cac:PartyTaxScheme>
      <cbc:CompanyID>GB123456789</cbc:CompanyID>
      <cac:TaxScheme>
        <cbc:ID>VAT</cbc:ID>
      </cac:TaxScheme>
    </cac:PartyTaxScheme>
    <!-- legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingSupplierParty>
```

The corrected invoice has `cbc:CompanyID` `GB123456789` at the top of the seller `cac:PartyTaxScheme`; the failing one keeps the `VAT` scheme and drops the number. The failing document also reports `BR-S-02`: its line is standard rated, which requires a seller VAT identifier, and that identifier is now missing. When tried, removing the entire seller `cac:PartyTaxScheme` instead cleared `UBL-SR-53` and left `BR-S-02`, so here only restoring the number fixes both.

### What the validator reported

- The failing invoice reports [BR-S-02](https://ironfang.uk/docs/finance/rules/BR-S-02.md) and **UBL-SR-53**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/UBL-SR-53-invalid.xml)
  - [Download the corrected XML](https://ironfang.uk/finance/rule-examples/invoice-minimal.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 credit notes as well. When tried, the same edit to a credit note reported the same two rules.
- Reported on the EN 16931 layer, which carries the UBL syntax rules of the EN 16931 binding.
- Which VAT category rule appears alongside depends on the lines. When tried on an exempt invoice, the same edit brought `BR-E-02` in place of `BR-S-02`.
- On the tax representative, a block without its number is also reported by `BR-56`.

## Related rules

- [BR-S-02 is reported with this rule when the missing number is the seller VAT identifier on a standard rated invoice](https://ironfang.uk/docs/finance/rules/BR-S-02.md)
- [BR-56 requires the tax representative VAT identifier, and fires with this rule when only the number is missing](https://ironfang.uk/docs/finance/rules/BR-56.md)
- [BR-CO-09 checks the country prefix of the CompanyID once it is present](https://ironfang.uk/docs/finance/rules/BR-CO-09.md)
- [PEPPOL-EN16931-R008 reports a CompanyID that is present but empty, which this rule accepts](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R008.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-24.1: source checked 2026-09-24, explanation last updated 2026-09-24.

[The official definition of UBL-SR-53](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/UBL-SR-53/) 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.uk/docs/finance/rules/UBL-SR-53)
- [Free Peppol invoice validator](https://ironfang.uk/tools/peppol-validator)
- [Rule index](https://ironfang.uk/docs/finance/rules.md)
- [Ironfang Finance API docs](https://ironfang.uk/docs/finance)
- The same rule is available to MCP clients as the tool `finance.rule.get` on https://mcp.ironfang.uk/mcp