Automation MCP Server Features Blog Pricing Contact
Identifier reference Peppol BIS CIUS

urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0

The CustomizationID of Peppol BIS Billing 3.0, the rule set every invoice on the Peppol network is measured against. It never travels alone: a ProfileID declaring the business process rides alongside it, and both must be right for an access point to let the document through.

What this identifier declares

This string is the CustomizationID (BT-24) of Peppol BIS Billing 3.0, the specification every invoice and credit note on the Peppol network must satisfy. Read it through its grammar: the document follows the EN 16931 core model, remains compliant with it (BIS is a CIUS, a strict subset), and applies the Peppol BIS Billing 3.0 overlay maintained by OpenPeppol's Post-Award Coordinating Community (the poacc in the string).

Declaring it is not a formality. Peppol access points validate at the network edge, and this identifier is what tells them which gate the document has chosen. There is no lighter option: an invoice on the network either declares and passes BIS Billing 3.0 or it does not travel.

Where it appears in the XML

BIS Billing 3.0 is bound to UBL 2.1, so the identifier lives in cbc:CustomizationID, and its companion, the ProfileID (BT-23), sits directly below it:

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

The pair divides the work: the CustomizationID names the rule set, the ProfileID names the business process (Peppol billing). Both are mandatory, and the same values appear in the document's SBDH envelope routing metadata when it travels between access points.

What validators derive from it

The identifier routes validation to the BIS Billing 3.0 artifacts: the UBL 2.1 schema, the EN 16931 core rules, and the Peppol rule layer (rule IDs starting PEPPOL-EN16931-), which tightens identifiers, code lists, and VAT logic beyond the core. The InvoiceXML UBL validator detects the profile from BT-24, applies the currently effective BIS revision, reports the applied rule set in data.profile, and names the violated rule in every finding. Peppol revises the rules every spring and autumn on scheduled effective dates; the identifier stays constant while the rulebook underneath it moves, and InvoiceXML switches server-side on each effective date.

Common problems around this identifier

  • Missing or mismatched ProfileID. A correct CustomizationID with an absent or wrong BT-23 still fails BIS validation. They are checked as a pair.
  • Bare EN 16931 on the network. Declaring the plain core identifier gets a structurally fine invoice rejected at the access point: the network requires its own CIUS, not the stem.
  • Rule-release drift. Integrations that vendored the BIS artifacts once and never updated start failing on rules added in later releases, with the identifier unchanged the whole time. If validation results changed and your XML did not, look at the release calendar.

Working with Peppol BIS documents

To check any UBL file against the current BIS rules, the UBL validator runs in the browser or over the API. To produce network-ready documents, the create endpoint stamps both identifiers, computes totals, and validates against the effective BIS revision before delivery, so what leaves the API is what the access point will accept. The Peppol hub covers the network and its national flavours, and the UBL API toolkit is the full integration guide.

Frequently asked questions

What is the difference between the CustomizationID and the ProfileID?

The CustomizationID (BT-24) names the rule set the document claims to satisfy: the Peppol BIS Billing 3.0 CIUS of EN 16931. The ProfileID (BT-23), urn:fdc:peppol.eu:2017:poacc:billing:01:1.0, names the business process the document takes part in: Peppol's billing process. BIS 3.0 requires both, and validators check both.

Does the identifier change when Peppol publishes a new BIS release?

No. Peppol ships rule updates every spring and autumn with scheduled effective dates, but the CustomizationID has stayed the same throughout BIS Billing 3.0's life. The string tells you which specification applies, not which rule revision; the network applies the currently effective revision automatically.

Is Peppol BIS Billing 3.0 UBL only?

For the invoice and credit note documents, yes: BIS Billing 3.0 is bound to UBL 2.1. A CII invoice cannot carry this CustomizationID meaningfully; to put invoice data onto the Peppol network you produce a UBL document declaring this identifier and process.

How do NLCIUS and EHF relate to this identifier?

They are national specifications riding on Peppol. Dutch NLCIUS declares its own CustomizationID (urn:cen.eu:en16931:2017#compliant#urn:fdc:nen.nl:nlcius:v1.0), while Norwegian EHF Billing 3.0 appends a #conformant# segment to the BIS identifier. In both markets the Peppol BIS layer still applies underneath the national rules.