# BR-07: Add the buyer name as the customer RegistrationName

The customer party needs a non-empty `cbc:RegistrationName` inside `cac:PartyLegalEntity`. An empty element fails, and so does leaving it out.

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

## The short answer

`BR-07` fails when `cac:AccountingCustomerParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName` is missing or empty. Write the full name of the customer being invoiced into that element.

It is the counterpart of `BR-06` on the other party. Both can fail in the same document, and both findings are located at the document root, so check the rule id to see which party is meant.

## What the rule checks

The rule takes `cbc:RegistrationName` from the customer `cac:PartyLegalEntity` and fails when the element is not there or contains only whitespace. A buyer trading name in `cac:PartyName/cbc:Name` is a different field and does not satisfy it.

Missing versus empty: neither `cac:PartyLegalEntity` nor its `cbc:RegistrationName` is mandatory in the UBL schema, so omitting them gets through the XSD layer and the document reports `BR-07` alone. The recorded example has the element present but empty, which adds `PEPPOL-EN16931-R008` to the report.

The content is not inspected beyond being non-blank. The rule does not compare the name with the buyer electronic address, a registration number or any directory.

| Term | Meaning | UBL element |
|---|---|---|
| BT-44 | Buyer name | `cac:AccountingCustomerParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName` |

## How an integration ends up here

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

- The customer record has a contact person and an address, but the company name field was never filled in.
- The customer is a private individual, and the mapping reads a company-name column that is blank for people.
- The name is taken from the delivery address or the ordering contact and that record is incomplete, while the billing account holds the real name.
- The customer name is joined in from a CRM or master-data service and the join returns nothing for archived or merged accounts.
- The serialiser emits `cac:PartyLegalEntity` to carry the buyer registration number and writes the name as an empty element when the value is null.

## How to fix it

1. Decide which source record is the invoiced customer, normally the bill-to account, and take the name from there.
2. Write it to `cbc:RegistrationName` inside the customer `cac:PartyLegalEntity`. For an organisation use its registered name; for a person use their full name.
3. Make the name a required field at the point where the invoice is issued, so the gap is caught before the XML is built.

## Before and after

These are fragments, not complete documents. The complete synthetic documents they come from are linked below.

Customer party of the failing invoice: the name element is present and empty

```xml
<cac:AccountingCustomerParty>
  <cac:Party>
    <!-- endpoint and postal address omitted from this fragment -->
    <cac:PartyLegalEntity>
      <cbc:RegistrationName></cbc:RegistrationName>
      <cbc:CompanyID>87654321</cbc:CompanyID>
    </cac:PartyLegalEntity>
  </cac:Party>
</cac:AccountingCustomerParty>
```

Customer party of the corrected invoice: the buyer is named

```xml
<cac:AccountingCustomerParty>
  <cac:Party>
    <!-- endpoint and postal address omitted from this fragment -->
    <cac:PartyLegalEntity>
      <cbc:RegistrationName>Example Buyer Ltd</cbc:RegistrationName>
      <cbc:CompanyID>87654321</cbc:CompanyID>
    </cac:PartyLegalEntity>
  </cac:Party>
</cac:AccountingCustomerParty>
```

Only the customer `cbc:RegistrationName` differs: it is empty in the failing invoice and reads `Example Buyer Ltd` in the corrected one. The failing document also reports `PEPPOL-EN16931-R008`, because the empty name is a childless element with no text, which Peppol forbids anywhere in a document. Naming the buyer clears both.

### What the validator reported

- The failing invoice reports **BR-07** and [PEPPOL-EN16931-R008](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R008.md). The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/BR-07-invalid.xml)
  - [Download the corrected XML](https://ironfang.uk/finance/rule-examples/invoice-minimal.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

- Applies to UBL `Invoice` and `CreditNote` alike. A credit note with an empty buyer name reports `BR-07` and `PEPPOL-EN16931-R008`, and one with the element left out reports `BR-07` only.
- A valid buyer name says nothing about whether the buyer can be reached on the Peppol network. That depends on the electronic address and on the registration behind it.

## Related rules

- [BR-06 makes the same demand of the seller name](https://ironfang.uk/docs/finance/rules/BR-06.md)
- [PEPPOL-EN16931-R008 accompanies this rule when the name element is present but empty](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R008.md)
- [PEPPOL-EN16931-R010 requires the buyer electronic address in the same party](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R010.md)
- [PEPPOL-EN16931-R003 asks for a buyer reference or an order reference, another field that depends on customer data](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R003.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-20.

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