Peppol R004 and R007 errors: CustomizationID and ProfileID

PEPPOL-EN16931-R004 means your cbc:CustomizationID is wrong. PEPPOL-EN16931-R007 means your cbc:ProfileID is not an approved business process. Both are fatal. For a normal Peppol BIS Billing 3.0 invoice or credit note the two values must be exactly:

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

If those were working until August 2026 and then started failing, read the section on ::2.1 below.

The rules, as published in BIS 3.0.21

Rule	Message	Test
BR-01 (EN 16931)	"An Invoice shall have a Specification identifier (BT-24)."	CustomizationID not empty
R004	"Specification identifier MUST begin with the value 'urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0' and follow the format rules for the identifier."	starts-with(..., 'urn:cen.eu:...billing:3.0') and not(contains(..., '::'))
R001	"Business process MUST be provided."	cbc:ProfileID exists
R007	"Business process MUST have an approved identifier."	$profile != 'Unknown'

The $profile variable in the 3.0.21 Peppol schematron is set to:

• '01' for urn:fdc:peppol.eu:2017:poacc:billing:01:1.0, and for two temporary French profiles, urn:peppol:france:billing:regulated and urn:peppol:france:billing:non-regulated
• '02' for urn:peppol:bis:billing_with_response
• 'Unknown' for anything else, which triggers R007

The '::2.1' trap (new in 3.0.21)

The 3.0.21 release notes say: "Fatal rule PEPPOL-EN16931-R004 in UBL and CII schematron updated to reflect the correct requirement for CustomizationID without version information." The release was published on 20 May 2026 and is "Mandatory to use from: 2026-08-17".

The usual cause is confusing two identifiers that look alike:

Identifier	Where it is used	Value
Customization ID	cbc:CustomizationID in the invoice	urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0
Document type ID	SMP registration and SBDH envelope	urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1

The Peppol Policy for use of Identifiers (POLICY 20) defines the document type pattern as <syntax specific id>##<customization id>::<version>, where the version "is used to reflect the version of the underlying format standard (e.g. the UBL version)". POLICY 18 says the CustomizationID in a UBL document "must correspond to the Customization ID of the Document Type Identifier": the part between ## and ::, not the whole string.

What we tested

Changing one value at a time in a valid UK invoice, against the BIS 3.0.21 rules:

Value sent	Result
CustomizationID ...billing:3.0::2.1	R004 fatal
CustomizationID = the full document type ID	R004 fatal
CustomizationID urn:cen.eu:en16931:2017	R004 fatal
CustomizationID urn:fdc:peppol.eu:2017:poacc:billing:3.0 (missing prefix)	R004 fatal
No ProfileID	R001 and R007 fatal
ProfileID urn:peppol:bis:billing (a PINT process)	R007 fatal
ProfileID urn:fdc:peppol.eu:2017:poacc:billing:1.0 (missing 01)	R007 fatal
ProfileID with ::2.1 appended	R007 fatal
ProfileID in upper case	R007 fatal
ProfileID urn:peppol:bis:billing_with_response	Passes

Upper case fails because the comparison is exact. The Identifier Policy says "All Process Identifier values have to be treated case sensitive" and the same for document type identifiers (POLICY 2).

Extensions

R004 uses starts-with, so a CustomizationID that extends the BIS value, such as ...billing:3.0#conformant#urn:..., passes the rule. That does not mean it will be delivered. The Customization ID is part of the document type identifier your Access Point looks up in the receiver's SMP. If the receiver has not registered that exact document type, the lookup fails before validation matters. National extensions are listed in the Peppol code lists (v9.7); there is no UK one today.

Where wrong values come from

1. Copied from an SMP or Peppol Directory record. Those show the document type identifier with ::2.1.
2. An Access Point API that asks for "document type". Some APIs want the full document type ID for routing, separate from the XML. Do not paste it into the XML as well.
3. Old templates. BIS 2.0 used different identifiers and now fails R004.
4. PINT confusion. urn:peppol:bis:billing is a process for Peppol International (PINT) documents, not for BIS Billing 3.0.
5. Hand-edited XML. Trailing characters, case changes or a missing #compliant#.

Log parsers: rule IDs in messages

Another 3.0.21 change: "Texts for Peppol rules are now prefixed with rule identifier". A message that used to read "Business process MUST be provided." now reads "[PEPPOL-EN16931-R001]-Business process MUST be provided." If your system matches error text to decide what to do, match on the rule ID instead.

Not yet settled for the UK

The UK has not published a data specification. If it adopts BIS Billing 3.0 unchanged, these identifiers stay as they are. If it publishes a UK specialisation, the CustomizationID would change for UK documents. Neither is confirmed. See Peppol BIS Billing 3.0: a UK guide.

What to do now

• Hard-code the two values above and keep them out of user-editable settings.
• Keep the SMP document type ID in your routing layer only.
• Re-test old templates against the 3.0.21 rules in the e-invoice validator.

Related: Peppol SBDH envelope explained, SMP and SML explained, common Peppol validation errors.