# BR-CO-26: Give the seller a VAT, legal registration or seller identifier
The seller must carry at least one of a VAT identifier, a seller identifier in `cac:PartyIdentification`, or a legal registration identifier.
- Layer: EN 16931
- Severity: fatal (the document is invalid)
- Topics: Parties and addresses
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-CO-26/
- Explanation last updated: 2026-09-24
## The short answer
`BR-CO-26` fails when `cac:AccountingSupplierParty/cac:Party` has none of three identifiers: a `cbc:CompanyID` in a `VAT` `cac:PartyTaxScheme`, a `cac:PartyIdentification/cbc:ID` whose scheme is not `SEPA`, or a `cac:PartyLegalEntity/cbc:CompanyID`. Add whichever the seller really has; in the recorded example it is the legal registration identifier `12345678`.
On a not subject to VAT document, like the recorded one, the VAT identifier is not available: `BR-O-02` forbids it. Use the legal registration identifier or a seller identifier there.
## What the rule checks
The rule runs on `cac:AccountingSupplierParty` and reports there. Only the seller party is read: on an export with a tax representative VAT identifier and no seller identifier of any kind, `BR-G-02` passed when tried but `BR-CO-26` still failed.
The VAT route needs a `cac:PartyTaxScheme` with `cac:TaxScheme/cbc:ID` of `VAT` and a `cbc:CompanyID`. A seller registration under the scheme `TAX`, where a non-VAT tax registration goes, does not count: added to the failing invoice, it left the rule failing when tried.
The seller identifier route takes `cac:PartyIdentification/cbc:ID` with any `schemeID` except `SEPA`, or with none. When tried, `SUPPLIER-001` without a scheme and the GLN `7300010000001` with scheme `0088` each gave a valid document. A `SEPA` identifier alone failed, because under that scheme the element is the creditor identifier for direct debits; next to a second, non-SEPA identifier it passed.
The legal registration route takes `cac:PartyLegalEntity/cbc:CompanyID`, with or without a `schemeID`; a value with scheme `0088` passed when tried.
Nothing else stands in. The failing invoice has an electronic address in `cbc:EndpointID` and a `cbc:RegistrationName`, and a `cac:PartyName` added to it also failed when tried.
Presence satisfies the rule. An empty `cbc:CompanyID` in `cac:PartyLegalEntity`, or an empty `cac:PartyIdentification/cbc:ID`, passed it when tried and was reported by `PEPPOL-EN16931-R008` instead.
| Term | Meaning | UBL element |
|---|---|---|
| BT-29 | Seller identifier | `cac:AccountingSupplierParty/cac:Party/cac:PartyIdentification/cbc:ID` |
| BT-30 | Seller legal registration identifier | `cac:AccountingSupplierParty/cac:Party/cac:PartyLegalEntity/cbc:CompanyID` |
| BT-31 | Seller VAT identifier | `cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID` |
## How an integration ends up here
Possible causes, from the shape of the rule rather than from measured usage:
- The seller VAT identifier was taken out, for example to clear `BR-O-02` on a not subject to VAT invoice, and nothing else identified the seller.
- The company registration number is kept in company settings but mapped only to the printed invoice, not to `cac:PartyLegalEntity`.
- The only `cac:PartyIdentification` is the direct debit creditor identifier with scheme `SEPA`.
- The seller has no VAT registration and the export writes seller identifiers only when a VAT number exists.
- The mapping treats the Peppol electronic address in `cbc:EndpointID` as the seller identification.
## How to fix it
1. Choose from the registrations the seller actually holds: a company registration number, such as a Companies House number for a UK company; a VAT identifier where the document allows one; or an identifier such as a GLN under its ICD scheme.
2. For a registration number, write `cbc:CompanyID` inside `cac:PartyLegalEntity`, after `cbc:RegistrationName`. For a seller identifier, add `cac:PartyIdentification` with `cbc:ID` after `cbc:EndpointID` and before `cac:PostalAddress`.
3. Mind the scheme rules on `cac:PartyIdentification/cbc:ID` if you send a `schemeID`: a scheme outside the ISO 6523 ICD list reported `BR-CL-10` when tried, and a GLN with a wrong check digit under `0088` reported `PEPPOL-COMMON-R040`.
4. On a document with `O` lines, do not reach for the VAT identifier: when tried, it cleared `BR-CO-26` and brought `BR-O-02` in its place.
## 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 has a name and an electronic address but no identifier
```xml
7300010000001
Example Supplier Ltd
```
Fragment of the corrected invoice: the legal registration identifier follows the registration name
```xml
7300010000001
Example Supplier Ltd
12345678
```
The corrected invoice has `cbc:CompanyID` `12345678` in the seller `cac:PartyLegalEntity`; the failing invoice has the registration name alone. Neither document gives the seller a VAT identifier or a `cac:PartyIdentification`, because the invoice is not subject to VAT, so the legal registration identifier is all that identifies the seller. The failing document reports only `BR-CO-26`, although the seller keeps its electronic address.
### What the validator reported
- The failing invoice reports **BR-CO-26**. The corrected document passes every layer with no findings.
- [Download the failing XML](https://ironfang.uk/finance/rule-examples/BR-CO-26-invalid.xml)
- [Download the corrected XML](https://ironfang.uk/finance/rule-examples/not-subject-valid.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`. The failing invoice as a credit note reported `BR-CO-26` at the seller party when tried.
- The rule has no condition on VAT categories: every document needs one of the three seller identifiers, whether or not VAT is charged.
- National rules can narrow the choice. For suppliers in the Netherlands, `NL-R-003` limits which schemes the legal registration identifier may use.
## Related rules
- [BR-O-02 removes the VAT identifier as an option when a line is not subject to VAT](https://ironfang.uk/docs/finance/rules/BR-O-02.md)
- [BR-CL-10 checks that a seller identifier in cac:PartyIdentification uses a listed scheme](https://ironfang.uk/docs/finance/rules/BR-CL-10.md)
- [NL-R-003 restricts the legal registration identifier scheme for Dutch suppliers](https://ironfang.uk/docs/finance/rules/NL-R-003.md)
- [BR-G-02 needs a seller VAT identifier on exports, which a legal registration identifier cannot replace](https://ironfang.uk/docs/finance/rules/BR-G-02.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-24.
[The official definition of BR-CO-26](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-CO-26/) 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-CO-26)
- [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