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:CustomizationIDby 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
- Emit
cbc:ProfileIDas the second child of the root, immediately aftercbc:CustomizationID. The UBL schema fixes that order. - 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. - Do the same for
CreditNotedocuments; the element name and position are identical.
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 header goes from the specification identifier straight to the invoice number
<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
<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. 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. A credit note withoutcbc:ProfileIDreports 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
- BR-01 requires the specification identifier to be present at all
- PEPPOL-EN16931-R008 is what an empty business process element reports
- PEPPOL-EN16931-R003 is another Peppol-only header requirement: a buyer or order reference
- 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 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.