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

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.

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.

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

<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

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

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
• BR-CL-10 checks the scheme of a payee identifier and accepts SEPA there
• PEPPOL-EN16931-R008 reports a payee name element that is present but empty
• 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-24.1: source checked 2026-09-24, explanation last updated 2026-09-24.

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