# BR-01: Add the specification identifier in CustomizationID

The document root needs a non-empty `cbc:CustomizationID`. For Peppol BIS Billing 3.0 it is a fixed value, not something read from source data.

- Layer: EN 16931
- Severity: fatal (the document is invalid)
- Topics: Core fields, Process and references
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-01/
- Explanation last updated: 2026-09-20

## The short answer

`BR-01` fails when the `Invoice` or `CreditNote` root has no `cbc:CustomizationID`, or has one with nothing in it. Add the element ahead of `cbc:ProfileID` and give it the Peppol BIS Billing 3.0 value: `urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0`.

This rule only asks for some text. Whether the text is the right identifier is a separate check, `PEPPOL-EN16931-R004`, and a missing identifier fails both.

## What the rule checks

The rule looks at the `cbc:CustomizationID` that is a direct child of the document root and fails when it is absent or contains only whitespace. Any other text satisfies it: a document carrying the bare `urn:cen.eu:en16931:2017` passes `BR-01` and is reported by `PEPPOL-EN16931-R004` alone.

Missing and empty behave slightly differently. The UBL schema treats `cbc:CustomizationID` as optional, so a document with no such element passes the XSD layer and reports `BR-01` and `PEPPOL-EN16931-R004`. An element that is present but empty, or holds only whitespace, reports those two and also `PEPPOL-EN16931-R008`, the Peppol rule against empty elements.

Whitespace around a correct value is harmless here. A pretty-printed element with the identifier on its own line passes every layer.

| Term | Meaning | UBL element |
|---|---|---|
| BT-24 | Specification identifier | `cbc:CustomizationID` |

## How an integration ends up here

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

- The identifier is a configuration constant that was set for the invoice template but never for the credit note template.
- The serialiser drops elements whose source value is null, and the identifier is looked up per recipient or per profile from a table that has no row for this case.
- The same lookup returns an empty string, so the element is written with no content.
- The UBL export was built for a non-Peppol recipient and never carried a specification identifier.
- The integration fills in the identifier on the transport envelope and assumes the document itself does not need it.

## How to fix it

1. Emit `cbc:CustomizationID` as a direct child of the `Invoice` or `CreditNote` root, before `cbc:ProfileID`.
2. Set it from a constant for the specification you produce. For Peppol BIS Billing 3.0 that is `urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0`.
3. Apply the same constant to credit notes; the element and the value are identical.
4. Leave `cbc:ProfileID` as the business process identifier. The two are different fields and one cannot stand in for the other.

## 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 root goes straight to the profile identifier

```xml
<!-- first children of the Invoice root; there is no 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 -->
```

Start of the corrected invoice: the specification identifier comes first

```xml
<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 -->
```

The corrected invoice has the `cbc:CustomizationID` element and the failing one does not; nothing else differs. The failing document also reports `PEPPOL-EN16931-R004`, which requires the identifier to begin with the Peppol BIS Billing 3.0 value and cannot be met by an identifier that is not there. Adding the element with that value clears both.

### What the validator reported

- The failing invoice reports **BR-01** and [PEPPOL-EN16931-R004](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R004.md). The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/invoice-missing-customization.xml)
  - [Download the corrected XML](https://ironfang.uk/finance/rule-examples/invoice-minimal.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` alike. The recorded credit note without the element reports the same two rules.
- The value given here is the one for Peppol BIS Billing 3.0, which is the scope of this reference. Other specifications built on EN 16931 have their own identifiers and their own rules for them.
- The identifier states which specification the document claims to follow. It says nothing about whether the receiver is registered to accept that document type.

## Related rules

- [PEPPOL-EN16931-R004 checks that the identifier is the Peppol BIS Billing 3.0 one](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R004.md)
- [PEPPOL-EN16931-R001 is the matching presence check for the business process in ProfileID](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R001.md)
- [PEPPOL-EN16931-R008 is reported as well when the element is present but empty](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R008.md)
- [BR-02 is the same kind of check for the invoice number](https://ironfang.uk/docs/finance/rules/BR-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-20.

[The official definition of BR-01](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-01/) 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-01)
- [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