The short answer
BR-10 fails when there is no cac:PostalAddress inside cac:AccountingCustomerParty/cac:Party. Add the postal address of the customer you are invoicing there, including cac:Country/cbc:IdentificationCode.
A delivery address does not satisfy it. The ship-to address belongs under cac:Delivery, and the rule reads only the buyer party.
What the rule checks
This is a presence check on a single element: cac:PostalAddress as a direct child of the buyer cac:Party. The rule does not read the content of the address.
An address group with no children passes BR-10. When tried, <cac:PostalAddress/> in the buyer party was reported instead by BR-11, for the missing country code, and by PEPPOL-EN16931-R008, for the empty element.
The smallest buyer address that passes all layers is one holding only the country code: when tried, a buyer cac:PostalAddress containing just cac:Country/cbc:IdentificationCode produced no findings.
The rule is evaluated against the document as a whole, so the finding location is the root element rather than the buyer party.
| Term | Meaning | UBL element |
|---|---|---|
| BG-8 | Buyer postal address | cac:AccountingCustomerParty/cac:Party/cac:PostalAddress |
| BT-55 | Buyer country code | cac:AccountingCustomerParty/cac:Party/cac:PostalAddress/cac:Country/cbc:IdentificationCode |
How an integration ends up here
Possible causes, from the shape of the rule rather than from measured usage:
- Customers set up for electronic invoicing were created with a name and an electronic address only, and the address fields were never filled.
- The only address on the order is the ship-to, and the mapping writes it to
cac:Deliveryand leaves the buyer party without one. - The builder skips the address block whenever the street is blank, even when a city and country are known.
- Buyer details come from a customer reference on the order that carries identifiers but not the address.
How to fix it
- Read the postal address of the buyer from the customer master record: the party being invoiced, not the delivery point.
- Emit it as
cac:PostalAddressinsidecac:AccountingCustomerParty/cac:Party, aftercac:PartyNameif present and beforecac:PartyTaxSchemeandcac:PartyLegalEntity. - End the address with
cac:Country/cbc:IdentificationCodeholding the two-letter ISO 3166-1 code; without it the next finding isBR-11. - Where the customer record has no address, complete the record. Copying the seller or delivery address into the buyer party states something untrue about the buyer.
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 buyer party has an electronic address and a legal entity but no postal address
<cac:AccountingCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
<cac:PartyLegalEntity>
<cbc:RegistrationName>Example Buyer Ltd</cbc:RegistrationName>
<cbc:CompanyID>87654321</cbc:CompanyID>
</cac:PartyLegalEntity>
</cac:Party>
</cac:AccountingCustomerParty>Fragment of the corrected invoice: the buyer postal address comes before the legal entity
<cac:AccountingCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
<cac:PostalAddress>
<cbc:StreetName>2 Example Street</cbc:StreetName>
<cbc:CityName>London</cbc:CityName>
<cbc:PostalZone>SW1A 2AA</cbc:PostalZone>
<cac:Country>
<cbc:IdentificationCode>GB</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>
<cac:PartyLegalEntity>
<cbc:RegistrationName>Example Buyer Ltd</cbc:RegistrationName>
<cbc:CompanyID>87654321</cbc:CompanyID>
</cac:PartyLegalEntity>
</cac:Party>
</cac:AccountingCustomerParty>The only difference is the buyer cac:PostalAddress, with street, city, postcode and country GB, between the buyer cbc:EndpointID and cac:PartyLegalEntity. The failing document reports BR-10 and nothing else. BR-11 does not appear, because its check runs inside the buyer address and the failing document has none.
What the validator reported
- The failing invoice reports BR-10. 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
- Credit notes need the buyer address in the same place. When tried, removing it from a credit note reported
BR-10at theCreditNoteroot. - This is an EN 16931 finding. The recorded failing invoice has a clean Peppol layer, so the buyer address requirement reaches you from EN 16931 alone.
- A document missing both the seller and the buyer address reports
BR-08andBR-10together. - An address placed after
cac:PartyLegalEntitybreaks the UBL element order and is rejected at the XSD layer, so this rule is not reached.
Related rules
- BR-11 requires the country code inside the buyer address once the address exists
- BR-08 is the same presence check for the seller postal address
- BR-07 requires the buyer legal name in the same party
- BR-CL-14 checks that the buyer country code is a valid ISO 3166-1 code
- 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-10 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.
