BR-19: Add a postal address to the seller tax representative

The short answer

BR-19 fails when a cac:TaxRepresentativeParty has no cac:PostalAddress. Add the address of the tax representative between its cac:PartyName and its cac:PartyTaxScheme, with at least a country code, which BR-20 asks for next.

The rule only applies because the representative group is present. If the seller has not appointed a tax representative for this supply, remove cac:TaxRepresentativeParty altogether rather than completing it.

What the rule checks

The rule is evaluated once per cac:TaxRepresentativeParty and reports at that element. It passes as soon as a cac:PostalAddress child exists; what the address holds is left to BR-20.

An empty <cac:PostalAddress/> therefore gets past it. When tried, that empty element was reported by BR-20, since the address has no country code, and by PEPPOL-EN16931-R008, while BR-19 stayed silent.

A country code on its own satisfies both address rules. When tried, a representative address holding only cac:Country/cbc:IdentificationCode of GB, with no street, city or postcode, passed every layer.

The address has a fixed place among the children of the party. When tried, a representative address placed after cac:PartyTaxScheme failed the XSD layer, and no business rule ran.

How an integration ends up here

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

• The representative is recorded as a name and a VAT number in a VAT registration table that has no address columns.
• The shared party builder writes an address only for the seller and buyer, and the representative block was added later from a different template.
• The representative block is emitted for every invoice from a seller registered abroad, with whatever fields happen to be filled, whether or not a representative was appointed.

How to fix it

1. Confirm that a tax representative applies to this invoice. If none does, drop cac:TaxRepresentativeParty; the group is optional.
2. Take the address from the appointment or registration record of the representative, not from the seller.
3. Write it as cac:PostalAddress directly after cac:PartyName and before cac:PartyTaxScheme, with street, city and postcode, and cac:Country/cbc:IdentificationCode as its last child.
4. Check the rest of the group while you are there: the representative name (BR-18) and its VAT identifier (BR-56).

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 goes from its name straight to its VAT identifier

<cac:TaxRepresentativeParty>
  <cac:PartyName>
    <cbc:Name>Example Fiscal Representative Ltd</cbc:Name>
  </cac:PartyName>
  <cac:PartyTaxScheme>
    <cbc:CompanyID>GB987654321</cbc:CompanyID>
    <!-- tax scheme omitted from this fragment -->
  </cac:PartyTaxScheme>
</cac:TaxRepresentativeParty>

Fragment of the corrected invoice: the representative address sits between the name and the VAT identifier

<cac:TaxRepresentativeParty>
  <cac:PartyName>
    <cbc:Name>Example Fiscal Representative Ltd</cbc:Name>
  </cac:PartyName>
  <cac:PostalAddress>
    <cbc:StreetName>4 Example Street</cbc:StreetName>
    <cbc:CityName>London</cbc:CityName>
    <cbc:PostalZone>SW1A 4AA</cbc:PostalZone>
    <cac:Country>
      <cbc:IdentificationCode>GB</cbc:IdentificationCode>
    </cac:Country>
  </cac:PostalAddress>
  <cac:PartyTaxScheme>
    <cbc:CompanyID>GB987654321</cbc:CompanyID>
    <!-- tax scheme omitted from this fragment -->
  </cac:PartyTaxScheme>
</cac:TaxRepresentativeParty>

The corrected invoice gives the tax representative a cac:PostalAddress at 4 Example Street, London, SW1A 4AA, country GB; the failing invoice has no address there and nothing else differs. BR-19 is the only finding. BR-20 is not reported, because it looks for the country code inside an address and there is no address for it to look in.

Where it applies

• The representative group has the same structure in a CreditNote. When tried, a credit note whose representative had no address reported BR-19 alone.
• An EN 16931 rule, reported on that layer only; the Peppol layer passed the recorded failing invoice.
• A document without cac:TaxRepresentativeParty is never tested, so the rule cannot fire for a seller that has no representative.

Related rules

• BR-20 requires a country code inside the address this rule asks for
• BR-18 requires the name of the same tax representative
• BR-56 requires the VAT identifier of the tax representative
• BR-08 is the matching requirement for the seller postal address
• 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-28.1: source checked 2026-09-28, explanation last updated 2026-09-28.

The official definition of BR-19 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.