# PEPPOL-EN16931-R001: Add the missing business process identifier

The document has no cbc:ProfileID. Add it directly under the root, after cbc:CustomizationID, with the Peppol Billing process identifier.

- Layer: Peppol BIS Billing
- Severity: fatal (the document is invalid)
- Topics: Process and references
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/PEPPOL-EN16931-R001/
- Explanation last updated: 2026-09-20

## The short answer

`PEPPOL-EN16931-R001` fails when the `Invoice` or `CreditNote` root has no `cbc:ProfileID` child. Add the element straight after `cbc:CustomizationID` and give it the Peppol Billing process identifier, `urn:fdc:peppol.eu:2017:poacc:billing:01:1.0`.

The same document will also report `PEPPOL-EN16931-R007`. That rule checks the value of the identifier, and a missing element has no approved value. Adding the element with the correct value clears both.

## What the rule checks

The rule is a presence check on one element: `cbc:ProfileID` as a direct child of the document root. It does not read the value.

Because only presence is tested, an empty `cbc:ProfileID` does not report this rule. It reports `PEPPOL-EN16931-R007` for the value and `PEPPOL-EN16931-R008` for the empty element instead.

A present element with an identifier the Peppol artefact does not recognise reports `PEPPOL-EN16931-R007` alone. Leading or trailing whitespace around a recognised identifier is ignored by that check.

| Term | Meaning | UBL element |
|---|---|---|
| BT-23 | Business process type | `cbc:ProfileID` |

## How an integration ends up here

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

- The mapping was built against plain EN 16931, where the business process type is optional, and the element was never added for Peppol.
- The process identifier is held as a per-customer or per-route setting and is blank for this recipient, so the serialiser skips the element.
- The identifier was written into `cbc:CustomizationID` by mistake, or the two identifiers were merged into one field in the source system.
- A template for credit notes was copied from the invoice template without the header identifiers.

## How to fix it

1. Emit `cbc:ProfileID` as the second child of the root, immediately after `cbc:CustomizationID`. The UBL schema fixes that order.
2. Set the value to `urn:fdc:peppol.eu:2017:poacc:billing:01:1.0`. Treat it as a constant of the Billing profile, not as data that varies by customer.
3. Do the same for `CreditNote` documents; the element name and position are identical.

## 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 header goes from the specification identifier straight to the invoice number

```xml
<cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0</cbc:CustomizationID>
<cbc:ID>EXAMPLE-INV-001</cbc:ID>
<cbc:IssueDate>2026-09-08</cbc:IssueDate>
<!-- rest of the document omitted from this fragment -->
```

Fragment of the corrected invoice: the business process identifier follows the specification identifier

```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 from this fragment -->
```

The only difference is the `cbc:ProfileID` line. The failing document reports two findings, both in the Peppol layer: `PEPPOL-EN16931-R001` because the element is absent, and `PEPPOL-EN16931-R007` because that rule derives the process from the identifier and, with nothing to read, treats it as unknown. The EN 16931 layer passes, since the core standard does not require the element.

### What the validator reported

- The failing invoice reports **PEPPOL-EN16931-R001** and [PEPPOL-EN16931-R007](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R007.md). The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/PEPPOL-EN16931-R001-invalid.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. A credit note without `cbc:ProfileID` reports the same two rules.
- This is a Peppol requirement on top of EN 16931. A document can pass the EN 16931 layer and still fail here.
- The rule does not look at `cbc:CustomizationID`. That identifier is checked separately and must also be present.

## Related rules

- [PEPPOL-EN16931-R004 checks the specification identifier that sits next to the business process](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R004.md)
- [BR-01 requires the specification identifier to be present at all](https://ironfang.uk/docs/finance/rules/BR-01.md)
- [PEPPOL-EN16931-R008 is what an empty business process element reports](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R008.md)
- [PEPPOL-EN16931-R003 is another Peppol-only header requirement: a buyer or order reference](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R003.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 PEPPOL-EN16931-R001](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/PEPPOL-EN16931-R001/) 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/PEPPOL-EN16931-R001)
- [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
