Skip to content

BR-07Add 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.

EN 16931Fatal: the document is invalidCore fieldsParties and addresses

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.

TermMeaningUBL element
BT-44Buyer namecac: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.

Validate your corrected invoice

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

<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

<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

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.

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-20.1: source checked 2026-09-20, explanation last updated 2026-09-20.

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