The short answer
BR-02 fails when the cbc:ID that sits directly under the Invoice or CreditNote root has no content. Write the number your system issued for the document into that element.
You will normally see this rule only for an element that is present but empty. If the element is left out altogether the XSD layer rejects the document first and this rule never runs.
What the rule checks
The rule reads one element, the cbc:ID child of the root, and fails when it holds nothing but whitespace. An element containing only an XML comment counts as empty too. Line identifiers, party identifiers and the cbc:ID inside cac:BillingReference on a credit note are different elements and play no part.
There is no format or uniqueness check. Any text at all passes this rule; keeping numbers unique and sequential is for the issuing system.
Missing versus empty: cbc:ID is mandatory in the UBL schema, so a document without it fails the XSD layer with a schema error, the EN 16931 and Peppol layers are skipped, and BR-02 is not reported. An empty or whitespace-only cbc:ID is valid against the schema, reaches the business rules, and reports BR-02 together with PEPPOL-EN16931-R008.
| Term | Meaning | UBL element |
|---|---|---|
| BT-1 | Invoice number | cbc:ID |
How an integration ends up here
Possible causes, from the shape of the rule rather than from measured usage:
- The XML is produced while the document is still a draft, before the numbering sequence has assigned a number.
- The mapping reads a field that is filled for invoices but not for credit notes, which are numbered from another sequence or column.
- The number is present in the source but the mapping points at the wrong property, so the serialiser writes an empty element.
- A preview or test export path skips the step that reserves the number.
How to fix it
- Find where the root-level
cbc:IDis populated and confirm which source field it reads for each document type. - Generate the XML only after the document has been issued and numbered.
- Write the number exactly as issued. A placeholder would get past this rule, since any text does, but the buyer reconciles on this value.
Validate your corrected invoice
Before and after
These are fragments, not complete documents. The complete synthetic documents they come from are linked below.
Start of the failing invoice: the document identifier is an empty element
<cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0</cbc:CustomizationID>
<cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>
<cbc:ID/>
<cbc:IssueDate>2026-09-08</cbc:IssueDate>
<!-- rest of the document omitted -->Start of the corrected invoice: the identifier carries the invoice number
<cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0</cbc:CustomizationID>
<cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>
<cbc:ID>EXAMPLE-INV-001</cbc:ID>
<cbc:IssueDate>2026-09-08</cbc:IssueDate>
<!-- rest of the document omitted -->Only the content of the root-level cbc:ID differs: empty in the failing invoice, EXAMPLE-INV-001 in the corrected one. The failing document also reports PEPPOL-EN16931-R008, because Peppol does not allow an element with no content anywhere in the document and the empty cbc:ID is one. Filling in the number clears both.
What the validator reported
- The failing invoice reports BR-02 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. On a credit note the same root-levelcbc:IDholds the credit note number, and an empty one reports the same two rules. - A credit note can also carry the number of the invoice it corrects, in
cac:BillingReference/cac:InvoiceDocumentReference/cbc:ID. That reference does not satisfy this rule and this rule does not check it.
Related rules
- PEPPOL-EN16931-R008 is reported alongside whenever the element is present but empty
- BR-01 is the neighbouring presence check for the specification identifier
- BR-06 applies the same kind of check to the seller name
- BR-CL-01 checks the document type code that follows the number and dates
- 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-02 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.
