# BR-56: Add the VAT identifier of the seller tax representative

A `cac:TaxRepresentativeParty` needs a `cac:PartyTaxScheme` with tax scheme `VAT` and a `cbc:CompanyID`: the VAT number of the representative itself.

- 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/BR-56/
- Explanation last updated: 2026-09-24

## The short answer

`BR-56` fails when `cac:TaxRepresentativeParty` has no `cac:PartyTaxScheme` that combines a `VAT` tax scheme with a `cbc:CompanyID`. Add the VAT number of the representative, prefix included, as `cbc:CompanyID` in a `cac:PartyTaxScheme` whose `cac:TaxScheme/cbc:ID` is `VAT`.

The number belongs to the representative, not to the seller. The seller VAT identifier goes in the seller party; copying it into the representative group identifies the wrong party.

## What the rule checks

For each `cac:TaxRepresentativeParty`, the rule looks for a `cac:PartyTaxScheme` child whose tax scheme ID, trimmed and upper-cased, is `VAT`, and passes if that scheme has a `cbc:CompanyID`. A failure is reported against the `cac:TaxRepresentativeParty` element.

The tax scheme has to be VAT. When tried, the same number under a tax scheme of `TAX` failed `BR-56`, while `vat` in lower case passed, because case is ignored.

Only the existence of `cbc:CompanyID` is tested. When tried, an empty `cbc:CompanyID` passed `BR-56` and was reported by `PEPPOL-EN16931-R008` instead; the country prefix of a filled one is the business of `BR-CO-09`.

Removing the number but keeping the tax scheme gives two findings. When tried, that reported `BR-56` together with `UBL-SR-53`, which rejects any `cac:PartyTaxScheme` without a `cbc:CompanyID`.

The legal entity is not a substitute: when tried, the number in `cac:PartyLegalEntity/cbc:CompanyID` left `BR-56` failing and added the warning `UBL-CR-335`.

| Term | Meaning | UBL element |
|---|---|---|
| BG-11 | Seller tax representative party | `cac:TaxRepresentativeParty` |
| BT-63 | Seller tax representative VAT identifier | `cac:TaxRepresentativeParty/cac:PartyTaxScheme/cbc:CompanyID` |
| BT-63 | Seller tax representative VAT identifier: its tax scheme | `cac:TaxRepresentativeParty/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 representative is set up with a name and address, and its VAT registration number sits in a separate tax registration table the export does not join.
- A party template shared with the other parties writes `cac:PartyTaxScheme` only when a VAT number field is filled, and the representative record has no such field.
- The VAT number is placed in `cac:PartyLegalEntity/cbc:CompanyID`, where a company registration number would go.
- The tax scheme for the representative is taken from a local tax type code rather than being set to `VAT`.

## How to fix it

1. Get the VAT identifier issued to the representative from its appointment or registration record. Do not substitute the seller VAT identifier, and do not construct one.
2. Write `cac:PartyTaxScheme` inside `cac:TaxRepresentativeParty`, after `cac:PostalAddress`, with `cbc:CompanyID` holding the number followed by `cac:TaxScheme/cbc:ID` set to `VAT`.
3. Send the identifier in full with its country prefix, such as `GB987654321`; `BR-CO-09` checks the prefix.
4. If the seller has no tax representative, remove the whole `cac:TaxRepresentativeParty` group instead of sending it without a VAT 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: the tax representative has a name and address but no tax scheme

```xml
<cac:TaxRepresentativeParty>
  <cac:PartyName>
    <cbc:Name>Example Fiscal Representative Ltd</cbc:Name>
  </cac:PartyName>
  <cac:PostalAddress>
    <cbc:StreetName>4 Example Street</cbc:StreetName>
    <!-- rest of the address omitted from this fragment -->
  </cac:PostalAddress>
</cac:TaxRepresentativeParty>
```

Fragment of the corrected invoice: the representative VAT number follows the address

```xml
<cac:TaxRepresentativeParty>
  <cac:PartyName>
    <cbc:Name>Example Fiscal Representative Ltd</cbc:Name>
  </cac:PartyName>
  <cac:PostalAddress>
    <cbc:StreetName>4 Example Street</cbc:StreetName>
    <!-- rest of the address omitted from this fragment -->
  </cac:PostalAddress>
  <cac:PartyTaxScheme>
    <cbc:CompanyID>GB987654321</cbc:CompanyID>
    <cac:TaxScheme>
      <cbc:ID>VAT</cbc:ID>
    </cac:TaxScheme>
  </cac:PartyTaxScheme>
</cac:TaxRepresentativeParty>
```

The corrected invoice has a `cac:PartyTaxScheme` in the representative group, with `cbc:CompanyID` `GB987654321` and tax scheme `VAT`, after the address; the failing invoice has no `cac:PartyTaxScheme` there at all. Only `BR-56` is reported. With the whole block gone there is no half-filled tax scheme for `UBL-SR-53` to report, and the seller keeps its own VAT identifier, so the standard rated line still satisfies `BR-S-02`.

### What the validator reported

- The failing invoice reports **BR-56**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/BR-56-invalid.xml)
  - [Download the corrected XML](https://ironfang.uk/finance/rule-examples/tax-representative-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

- A `CreditNote` representative is read the same way. When tried, a credit note whose representative kept the `VAT` scheme but lost the number reported `BR-56` and `UBL-SR-53`.
- A representative VAT identifier can meet `BR-S-02` on its own. When tried, removing the seller VAT identifier while keeping the representative one left the invoice valid; removing both reported `BR-56` and `BR-S-02`.
- EN 16931 raises this finding; the Peppol layer of the recorded failing invoice is clear.

## Related rules

- [BR-18 requires the name of the same tax representative](https://ironfang.uk/docs/finance/rules/BR-18.md)
- [UBL-SR-53 is reported alongside when the representative tax scheme is kept without its number](https://ironfang.uk/docs/finance/rules/UBL-SR-53.md)
- [BR-CO-09 checks the country prefix of the representative VAT identifier](https://ironfang.uk/docs/finance/rules/BR-CO-09.md)
- [BR-S-02 accepts the representative VAT identifier when the seller has none](https://ironfang.uk/docs/finance/rules/BR-S-02.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 BR-56](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-56/) 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/BR-56)
- [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