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

A `cac:TaxRepresentativeParty` must contain a `cac:PostalAddress`. Leave the group out if there is no representative, and send it complete if there is.

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

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

| Term | Meaning | UBL element |
|---|---|---|
| BG-11 | Seller tax representative party | `cac:TaxRepresentativeParty` |
| BG-12 | Seller tax representative postal address | `cac:TaxRepresentativeParty/cac:PostalAddress` |

## 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`).

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

```xml
<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

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

### What the validator reported

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

- 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](https://ironfang.com/docs/finance/rules/BR-20.md)
- [BR-18 requires the name of the same tax representative](https://ironfang.com/docs/finance/rules/BR-18.md)
- [BR-56 requires the VAT identifier of the tax representative](https://ironfang.com/docs/finance/rules/BR-56.md)
- [BR-08 is the matching requirement for the seller postal address](https://ironfang.com/docs/finance/rules/BR-08.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-28.1: source checked 2026-09-28, explanation last updated 2026-09-28.

[The official definition of BR-19](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/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.

## Links

- [This rule as a web page](https://ironfang.com/docs/finance/rules/BR-19)
- [Free Peppol invoice validator](https://ironfang.com/tools/peppol-validator)
- [Rule index](https://ironfang.com/docs/finance/rules.md)
- [Ironfang Finance API docs](https://ironfang.com/docs/finance)
- The same rule is available to MCP clients as the tool `finance.rule.get` on https://mcp.ironfang.com/mcp