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:PartyLegalEntityto carry the buyer registration number and writes the name as an empty element when the value is null.
How to fix it
- Decide which source record is the invoiced customer, normally the bill-to account, and take the name from there.
- Write it to
cbc:RegistrationNameinside the customercac:PartyLegalEntity. For an organisation use its registered name; for a person use their full name. - 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
- The failing invoice reports BR-07 and PEPPOL-EN16931-R008. The corrected document passes every layer with no findings.Download the failing XMLDownload the corrected 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
InvoiceandCreditNotealike. A credit note with an empty buyer name reportsBR-07andPEPPOL-EN16931-R008, and one with the element left out reportsBR-07only. - 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
- PEPPOL-EN16931-R008 accompanies this rule when the name element is present but empty
- PEPPOL-EN16931-R010 requires the buyer electronic address in the same party
- PEPPOL-EN16931-R003 asks for a buyer reference or an order reference, another field that depends on customer data
- Browse every rule in the reference
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.
