Skip to content

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.

EN 16931Fatal: the document is invalidParties and addressesVAT

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.

TermMeaningUBL element
BG-11Seller tax representative partycac:TaxRepresentativeParty
BT-63Seller tax representative VAT identifiercac:TaxRepresentativeParty/cac:PartyTaxScheme/cbc:CompanyID
BT-63Seller tax representative VAT identifier: its tax schemecac: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.

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: the tax representative has a name and address but no tax scheme

<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

<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

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.

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 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.