# BR-17: Name the payee, or remove a payee that is the seller

A `cac:PayeeParty` needs `cac:PartyName/cbc:Name`, and its name or identifier must not repeat the seller's. If the seller is paid, leave the payee out.

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

## The short answer

`BR-17` fails on a `cac:PayeeParty` that has no `cac:PartyName/cbc:Name`, or whose name or identifier is the same as the seller's. When someone other than the seller is to be paid, such as a factoring company, give that payee its own name in `cac:PayeeParty/cac:PartyName/cbc:Name`. When the seller is to be paid, remove `cac:PayeeParty` altogether.

A payee with no name also brings `UBL-SR-19`, `UBL-SR-20` and `UBL-SR-21` at the same element, although nothing in it repeats. Each of those rules pairs a limit of one with a check that the payee name differs from the seller legal name, and with no payee name that check cannot pass. Adding the name clears all four.

## What the rule checks

The rule runs on every `cac:PayeeParty` and passes only when three things hold: a `cac:PartyName/cbc:Name` exists; it does not equal any seller trading name in `cac:AccountingSupplierParty/cac:Party/cac:PartyName/cbc:Name`; and no payee `cac:PartyIdentification/cbc:ID` equals a seller `cac:PartyIdentification/cbc:ID`.

Both comparisons are exact string matches. When tried, a payee named `Example Trading`, the seller trading name, failed `BR-17` on its own, and so did a differently named payee carrying the seller identifier `7300010000001`. A payee named `EXAMPLE TRADING` passed, because the case differs, although it names the same business.

For the name, presence is what counts. When tried, an empty payee `cbc:Name` satisfied `BR-17` and was reported only by `PEPPOL-EN16931-R008`.

The seller legal name is compared by the companion rules, not by this one. When tried, a payee named `Example Supplier Ltd`, the seller `cbc:RegistrationName`, passed `BR-17` and failed `UBL-SR-19`, `UBL-SR-20` and `UBL-SR-21`.

The payee identifier is optional: when tried, a payee with only the name `Example Factoring Ltd` passed every layer.

| Term | Meaning | UBL element |
|---|---|---|
| BG-10 | Payee | `cac:PayeeParty` |
| BT-59 | Payee name | `cac:PayeeParty/cac:PartyName/cbc:Name` |
| BT-60 | Payee identifier | `cac:PayeeParty/cac:PartyIdentification/cbc:ID` |
| BT-28 | Seller trading name (compared with the payee name) | `cac:AccountingSupplierParty/cac:Party/cac:PartyName/cbc:Name` |
| BT-29 | Seller identifier (compared with the payee identifier) | `cac:AccountingSupplierParty/cac:Party/cac:PartyIdentification/cbc:ID` |

## How an integration ends up here

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

- The export always writes `cac:PayeeParty`, filled from the seller record, because the source system treats the seller as the default payee.
- The payee is stored as a reference or account number with no party name, so the builder can write `cac:PartyIdentification` but not `cac:PartyName`.
- A factoring or assignment arrangement is recorded against the invoice, and the payee block is built from the agreement reference without looking up the name of the factor.
- The seller trading name is copied into the payee name as a placeholder when the real payee is not known.

## How to fix it

1. Decide whether the invoice is to be paid to anyone other than the seller. The payee group exists for that case only, for example a receivable that has been factored or assigned.
2. If the seller is paid, drop `cac:PayeeParty` from the output. The account to pay into stays in `cac:PaymentMeans`.
3. If a third party is paid, take its name from the factoring or assignment agreement and write it to `cac:PayeeParty/cac:PartyName/cbc:Name`, after any `cac:PartyIdentification`.
4. Give the payee its own identifier, if it has one. Never reuse the seller identifier there, and do not alter the seller name to make the comparison pass.
5. Send at most one payee name, one payee identifier other than a SEPA creditor identifier, and one legal registration identifier; `UBL-SR-19`, `UBL-SR-20` and `UBL-SR-21` limit each to one.

## 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 payee has an identifier but no name

```xml
<cac:PayeeParty>
  <cac:PartyIdentification>
    <cbc:ID>PAYEE-001</cbc:ID>
  </cac:PartyIdentification>
</cac:PayeeParty>
```

Fragment of the corrected invoice: the payee is named, and the name differs from the seller's

```xml
<cac:PayeeParty>
  <cac:PartyIdentification>
    <cbc:ID>PAYEE-001</cbc:ID>
  </cac:PartyIdentification>
  <cac:PartyName>
    <cbc:Name>Example Factoring Ltd</cbc:Name>
  </cac:PartyName>
</cac:PayeeParty>
```

The corrected invoice has `cac:PartyName` with `Example Factoring Ltd` after the payee identifier; the failing one has the identifier alone. Besides `BR-17`, the failing document reports `UBL-SR-19`, `UBL-SR-20` and `UBL-SR-21`, all at `cac:PayeeParty`. None of them has found a repeat: each also requires the payee name to differ from the seller `cbc:RegistrationName`, `Example Supplier Ltd`, and a name that is not there fails that comparison. With the name added, all four clear. A second recorded example adds a payee named `Example Trading`, the seller trading name, and reports `BR-17` alone; there the payee is the seller and should be left out.

### What the validator reported

- The failing invoice reports **BR-17**, `UBL-SR-19`, `UBL-SR-20` and `UBL-SR-21`. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/BR-17-invalid.xml)
  - [Download the corrected XML](https://ironfang.uk/finance/rule-examples/payee-valid.xml)
- The failing invoice reports **BR-17**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/BR-17-same-as-seller-invalid.xml)
  - [Download the corrected XML](https://ironfang.uk/finance/rule-examples/invoice-rich.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

- Credit notes carry the payee in the same place. When tried, a credit note with a nameless payee reported the same four rules.
- All four findings come from the EN 16931 layer; the Peppol layer of the failing invoice reports nothing about the payee.
- Only `cac:PartyIdentification/cbc:ID` is compared with the seller. The seller electronic address, VAT identifier and legal registration identifier play no part in this rule.
- A SEPA creditor identifier can sit in the payee `cac:PartyIdentification` with `schemeID="SEPA"`. `UBL-SR-20` leaves it out of its count of payee identifiers.

## Related rules

- [BR-06 requires the seller RegistrationName, the value UBL-SR-19 to UBL-SR-21 compare the payee name with](https://ironfang.uk/docs/finance/rules/BR-06.md)
- [BR-CL-10 checks the scheme of a payee identifier and accepts SEPA there](https://ironfang.uk/docs/finance/rules/BR-CL-10.md)
- [PEPPOL-EN16931-R008 reports a payee name element that is present but empty](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R008.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-17](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-17/) 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-17)
- [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