Automation MCP Server Features Blog Pricing Contact
Validation rule Peppol BIS Billing 3.0

PEPPOL-EN16931-R001

Peppol documents declare not just what they are but which exchange process they take part in. PEPPOL-EN16931-R001 fails when the business process type (BT-23) is missing, usually because a generic EN 16931 invoice was pointed at the network.

What PEPPOL-EN16931-R001 checks

The rule requires that a Peppol BIS Billing 3.0 invoice declare a business process type, BT-23: in UBL the cbc:ProfileID element next to the CustomizationID. The Peppol network is process-oriented; receivers register which document types and processes they accept, and access points route on that registration. An invoice that does not say which process it belongs to cannot be matched against the receiver's capabilities, so the overlay rejects it before it travels.

Layer and formats

R001 belongs to the Peppol overlay, so findings carry "layer": "cius" and fire when a document is validated against the Peppol BIS profile, the default for UBL invoices declaring the Peppol BIS CustomizationID. Validated under the plain en16931 profile, the overlay drops away and the same document passes, which is the correct outcome for invoices never intended for the network.

Why it fails in practice

  • A generic EN 16931 pipeline feeds an access point. The documents were built for direct exchange, where BT-23 is optional, and the Peppol onboarding surfaces the gap.
  • The ProfileID was confused with the CustomizationID. Both are URNs under the root; templates regularly fill one and drop the other.
  • A truncated or homemade process value. The value must match the Peppol pattern; local inventions fail the companion format rule R007 even when R001 passes.

How to fix it

Declare the billing process alongside the customization:

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

In an InvoiceXML create request the field is invoice.businessProcessType, and with the Peppol profile selected the API stamps the standard billing process for you when the field is empty.

The raw rejection vs the InvoiceXML finding

A raw Schematron validator says only this:

<svrl:failed-assert id="PEPPOL-EN16931-R001" flag="fatal"
    location="/*:Invoice[namespace-uri()='urn:oasis:names:specification:ubl:schema:xsd:Invoice-2'][1]">
  <svrl:text>Business process MUST be provided.</svrl:text>
</svrl:failed-assert>

The InvoiceXML finding tells your user what to actually do:

{
  "rule": "PEPPOL-EN16931-R001",
  "layer": "cius",
  "line": null,
  "message": "Peppol BIS requires a business process type. Add the business process (usually urn:fdc:peppol.eu:2017:poacc:billing:01:1.0), or use the plain en16931 profile if the invoice is not meant for Peppol.",
  "btCodes": ["BT-23"],
  "fields": ["businessProcessType"],
  "raw": "[PEPPOL-EN16931-R001] CIUS: Business process MUST be provided."
}

The message names the usual correct value and the escape hatch, and fields maps the finding to the exact request property. No rule-code parsing in your integration, and clients can localize by the stable rule key.

Check or generate Peppol documents

Validate a file against the network rules in the UBL validator, or generate ready-to-send documents with POST /v1/create/ubl, where the Peppol profile stamps both identifiers in their current form. The Peppol hub covers the network end to end, including how access-point rejections map to findings.

Frequently asked questions

What value does BT-23 need on Peppol?

The billing process identifier, for ordinary invoicing urn:fdc:peppol.eu:2017:poacc:billing:01:1.0. In UBL it is cbc:ProfileID, directly under the root next to the CustomizationID. The companion rule R007 additionally checks the format of the value, so copy it exactly.

How is BT-23 different from BT-24?

BT-24, the specification identifier or CustomizationID, names the rulebook the document follows. BT-23, the business process or ProfileID, names the choreography it participates in. Peppol requires both; a plain EN 16931 invoice typically carries only BT-24.

My invoice is not meant for Peppol. Can I ignore this rule?

Yes, by validating under the profile that matches reality. R001 comes from the Peppol overlay; the same file checked as plain en16931 does not fire it. The rule matters exactly when an access point will carry the document.

Which layer does the finding appear in?

The cius layer: it is Peppol's tightening of the European core, applied when validating against the Peppol BIS profile, which the InvoiceXML UBL validator selects automatically for documents declaring the Peppol CustomizationID.