The short answer
PEPPOL-EN16931-R007 fails when the text of cbc:ProfileID is not one of the business process identifiers built into the Peppol rules. For Peppol BIS Billing, write urn:fdc:peppol.eu:2017:poacc:billing:01:1.0 exactly.
The recorded example wrote urn:fdc:peppol.eu:2017:poacc:billing:3.0, which is the tail of the specification identifier in cbc:CustomizationID, not a process. The two elements carry different values, and neither can stand in for the other.
What the rule checks
The Peppol rules derive a profile from cbc:ProfileID under the root. After trimming surrounding whitespace, the value must equal one of four identifiers: urn:fdc:peppol.eu:2017:poacc:billing:01:1.0, urn:peppol:bis:billing_with_response, urn:peppol:france:billing:regulated or urn:peppol:france:billing:non-regulated. Anything else counts as unknown, and unknown fails.
The comparison is exact and case-sensitive, with no prefix matching. When tried, the Billing identifier in upper case, the same identifier with extra text after it, the BIS 2 identifier urn:www.cenbii.eu:profile:bii04:ver2.0, the self-billing identifier and the full specification identifier were all reported.
A missing cbc:ProfileID also counts as unknown, so it reports this rule beside PEPPOL-EN16931-R001. An empty one reports this rule beside PEPPOL-EN16931-R008.
Other rules depend on the result. The Peppol type code checks PEPPOL-EN16931-P0100 and PEPPOL-EN16931-P0101 run only for a recognised process, so they stay silent while this rule fails.
| 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 specification version (
billing:3.0) was taken for the process identifier and used in both header elements. - The identifier was retyped with a change of case or an added suffix.
- A configuration carried over from Peppol BIS 2 still sends the BIS 2 profile identifier.
- The value of
cbc:CustomizationIDwas copied intocbc:ProfileID.
How to fix it
- Set
cbc:ProfileIDtourn:fdc:peppol.eu:2017:poacc:billing:01:1.0for Peppol BIS Billing invoices and credit notes, copied rather than retyped. - Use one of the other recognised identifiers only if the exchange you are part of calls for it; each names a different arrangement, not a version of the same one.
- Leave
cbc:CustomizationIDas the specification identifier,urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0. It plays no part in this rule. - Validate again after the fix: a type code outside the Peppol list is reported only once the process is recognised.
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 business process element holds the specification version
<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:3.0</cbc:ProfileID>
<cbc:ID>EXAMPLE-INV-001</cbc:ID>
<!-- rest of the document omitted from this fragment -->Fragment of the corrected invoice: the Peppol BIS Billing process 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>
<!-- rest of the document omitted from this fragment -->Only cbc:ProfileID differs: urn:fdc:peppol.eu:2017:poacc:billing:3.0 in the failing invoice and urn:fdc:peppol.eu:2017:poacc:billing:01:1.0 in the corrected one. The failing document reports only PEPPOL-EN16931-R007, located at the document root. EN 16931 does not constrain the business process value, so that layer passes.
What the validator reported
- The failing invoice reports 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 with the same wrong value reported this rule when tried. - This is a Peppol rule. The set of recognised identifiers belongs to the pinned Peppol release and can change from one release to the next.
- A self-billing process identifier is rejected by these Billing rules. A self-billed document belongs to the Peppol self-billing specification; relabelling its process identifier does not make it a Billing document.
Related rules
- PEPPOL-EN16931-R001 reports a business process element that is missing, and fires with this rule
- PEPPOL-EN16931-R004 checks the specification identifier that is easily confused with this one
- PEPPOL-EN16931-P0100 checks the invoice type code only once this rule passes
- PEPPOL-EN16931-R008 is reported with this rule when the business process element is empty
- Browse every rule in the reference
- Background: How Peppol invoice validation actually works
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 PEPPOL-EN16931-R007 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.