# BR-18: Add the name of the seller tax representative

A `cac:TaxRepresentativeParty` must carry a name in `cac:PartyName/cbc:Name`. A blank name fails, and a `cbc:RegistrationName` does not count.

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

## The short answer

`BR-18` fails when `cac:TaxRepresentativeParty` has no `cac:PartyName/cbc:Name`, or the name is blank. Put the name of the tax representative, the party accountable for VAT on the seller's behalf, in `cac:PartyName/cbc:Name` as the first child of `cac:TaxRepresentativeParty`.

Seller and buyer names go in `cac:PartyLegalEntity/cbc:RegistrationName`; the tax representative name does not. When tried, the name placed in a `cac:PartyLegalEntity` inside the representative left `BR-18` failing and added the warning `UBL-CR-335`, because the model has no legal entity for this party.

## What the rule checks

The rule runs once for each `cac:TaxRepresentativeParty` and reports at that element, so an invoice without a tax representative is never tested.

It trims the text of `cac:PartyName/cbc:Name` and fails if nothing remains. When tried, an empty name and a name of three spaces both reported `BR-18`, together with `PEPPOL-EN16931-R008` for the blank element.

Any visible text satisfies it. The rule cannot tell whether the name is the one on the representative appointment.

| Term | Meaning | UBL element |
|---|---|---|
| BG-11 | Seller tax representative party | `cac:TaxRepresentativeParty` |
| BT-62 | Seller tax representative name | `cac:TaxRepresentativeParty/cac:PartyName/cbc:Name` |

## How an integration ends up here

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

- The representative block is generated from a VAT registration record that holds the VAT number and address of the representative but not its name.
- A party builder shared with the seller and buyer writes the name only to `cac:PartyLegalEntity/cbc:RegistrationName`, which is right for them and wrong here.
- The block is written for every invoice from a seller registered abroad, with empty fields when no representative has been appointed.

## How to fix it

1. Confirm that the seller really has a tax representative for this invoice. If it does not, leave `cac:TaxRepresentativeParty` out; the group is optional.
2. Take the representative name from the appointment or registration record, and write it as `cac:TaxRepresentativeParty/cac:PartyName/cbc:Name`, before `cac:PostalAddress`.
3. Complete the rest of the group from the same record: the representative also needs a VAT identifier (`BR-56`), a postal address (`BR-19`) and a country code in that address (`BR-20`).
4. Do not add a `cac:PartyLegalEntity` to the representative; it is outside the model and draws a warning.

## 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 starts with its address and has no name

```xml
<cac:TaxRepresentativeParty>
  <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>
    <!-- tax scheme omitted from this fragment -->
  </cac:PartyTaxScheme>
</cac:TaxRepresentativeParty>
```

Fragment of the corrected invoice: PartyName comes first in the tax representative

```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>
    <!-- tax scheme omitted from this fragment -->
  </cac:PartyTaxScheme>
</cac:TaxRepresentativeParty>
```

The corrected invoice opens `cac:TaxRepresentativeParty` with `cac:PartyName` holding `Example Fiscal Representative Ltd`; nothing else differs. The failing document reports `BR-18` alone, because its representative still has an address with a country code and a VAT identifier.

### What the validator reported

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

- The tax representative has the same structure in a `CreditNote`. When tried, a credit note whose representative had no name reported `BR-18` alone.
- An EN 16931 rule. In the recorded example the name is the only thing wrong, and the Peppol layer has no finding.
- The seller and buyer name rules, `BR-06` and `BR-07`, read `cbc:RegistrationName`. A shared party mapping has to switch to `cac:PartyName` for the representative.

## Related rules

- [BR-56 requires the VAT identifier of the same tax representative](https://ironfang.uk/docs/finance/rules/BR-56.md)
- [BR-06 names the seller through RegistrationName, the element this rule does not read](https://ironfang.uk/docs/finance/rules/BR-06.md)
- [PEPPOL-EN16931-R008 is reported with this rule when the name element is present but blank](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R008.md)
- [BR-17 is the naming rule for the other optional party, a payee who is not the seller](https://ironfang.uk/docs/finance/rules/BR-17.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-18](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-18/) 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-18)
- [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