BR-08: Add the seller postal address

The short answer

BR-08 fails when cac:AccountingSupplierParty/cac:Party has no cac:PostalAddress child. Add the address of the selling entity there: at least cac:Country/cbc:IdentificationCode, and the street, city and postcode that the seller record holds.

The finding points at the document root, not at the seller party, since the check is made once for the whole document. An address written anywhere other than that one element, such as a registered address under cac:PartyLegalEntity, leaves the rule failing.

What the rule checks

The rule asks one question: is there a cac:PostalAddress directly inside cac:AccountingSupplierParty/cac:Party? What the address contains is not examined here.

An empty <cac:PostalAddress/> is enough to satisfy it. When tried, that empty element was reported instead by BR-09, which wants a seller country code inside the address, and by PEPPOL-EN16931-R008, which rejects empty elements. An address holding nothing but the country code passed every layer.

No other address stands in for this one. When tried, an address in cac:PartyLegalEntity/cac:RegistrationAddress left BR-08 failing and added the warning UBL-CR-185, which reports that element as outside the model. The buyer, tax representative and deliver-to addresses are separate groups with their own rules.

How an integration ends up here

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

• The seller address lives in company settings that the export does not read, and the seller party is built from the name and identifiers only.
• The address block is written only when a street line is present, so a seller record with a city and country but no street produces no cac:PostalAddress at all.
• The mapping sends the address to cac:PartyLegalEntity/cac:RegistrationAddress because it is the registered office, and nothing to cac:PostalAddress.
• The invoice is issued for a subsidiary or branch whose address was never configured, and the builder leaves the block out instead of stopping.

How to fix it

1. Take the address of the selling entity from its master data: the entity named in cac:PartyLegalEntity/cbc:RegistrationName, not a warehouse or remittance address.
2. Write it as cac:PostalAddress inside cac:AccountingSupplierParty/cac:Party, after cbc:EndpointID, cac:PartyIdentification and cac:PartyName and before cac:PartyTaxScheme.
3. Include cac:Country/cbc:IdentificationCode as the last child of the address, with the ISO 3166-1 alpha-2 code such as GB. BR-09 requires it and BR-CL-14 checks the value.
4. Send the street, city and postcode as well. The validator accepts an address with only a country, but that is the minimum the rules test, not a complete address.
5. If the seller record has no address, stop the export and complete the record. Do not copy the buyer address or a placeholder into the seller party.

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 seller party goes from its electronic address straight to its tax scheme

<cac:AccountingSupplierParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
    <cac:PartyTaxScheme>
      <cbc:CompanyID>GB123456789</cbc:CompanyID>
      <!-- tax scheme omitted from this fragment -->
    </cac:PartyTaxScheme>
    <!-- legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingSupplierParty>

Fragment of the corrected invoice: the seller postal address sits between the electronic address and the tax scheme

<cac:AccountingSupplierParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
    <cac:PostalAddress>
      <cbc:StreetName>1 Example Street</cbc:StreetName>
      <cbc:CityName>London</cbc:CityName>
      <cbc:PostalZone>SW1A 1AA</cbc:PostalZone>
      <cac:Country>
        <cbc:IdentificationCode>GB</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
    <cac:PartyTaxScheme>
      <cbc:CompanyID>GB123456789</cbc:CompanyID>
      <!-- tax scheme omitted from this fragment -->
    </cac:PartyTaxScheme>
    <!-- legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingSupplierParty>

The corrected invoice has a seller cac:PostalAddress with street, city, postcode and country GB; the failing invoice has no seller address and is otherwise identical. BR-08 is the only finding on the failing document. The seller country rule BR-09 stays silent, because it runs inside the address and there is no address for it to run in.

Where it applies

• A CreditNote carries the seller address in the same place. When tried, a credit note without it reported BR-08 alone, located at the CreditNote root.
• The requirement comes from EN 16931 and is reported on that layer; nothing on the Peppol layer objected to the missing seller address in the recorded example.
• An address in the wrong position among the children of cac:Party fails the XSD layer before this rule is reached: when tried, the seller address placed after cac:PartyLegalEntity gave an XSD failure, and the EN 16931 and Peppol layers were skipped.
• When both party addresses are missing, BR-08 and BR-10 are reported side by side, both at the root.

Related rules

• BR-10 is the same presence check for the buyer postal address
• BR-CL-14 checks that the country code in the address is a valid ISO 3166-1 code
• BR-06 requires the seller legal name in the same party
• PEPPOL-EN16931-R008 reports a seller address 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-08 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.