PEPPOL-EN16931-P0100: Use an invoice type code that Peppol BIS Billing allows

The short answer

PEPPOL-EN16931-P0100 fails when cbc:InvoiceTypeCode holds a code outside the Peppol BIS Billing list. Send 380 for a commercial invoice, or another code from that list that truly describes the document, such as 386 for a prepayment invoice or 383 for a debit note.

A code can be a genuine UNTDID 1001 invoice code, accepted by BR-CL-01, and still fail here. The recorded 325 is a proforma invoice, which does not claim payment; Peppol BIS Billing has no code for one, and relabelling it 380 would present a document that asks for nothing as a demand for payment.

What the rule checks

The rule reads cbc:InvoiceTypeCode, trims surrounding spaces and compares it with 26 codes: 71, 80, 82, 84, 102, 218, 219, 326, 331, 380, 382, 383, 384, 386, 388, 393, 395, 553, 575, 623, 780, 817, 870, 875, 876 and 877.

EN 16931 allows more invoice codes than that. When tried, 325, 389 (self-billed invoice) and 130 each passed BR-CL-01 and failed this rule alone.

It applies only when cbc:ProfileID is a business process identifier the Peppol rules recognise. Under an unrecognised process identifier, 325 produced PEPPOL-EN16931-R007 and no finding from this rule when tried, so fixing the process identifier can bring this rule up next.

Being on the list is not always enough. 326 (partial invoice) and 384 (corrected invoice) are listed, but PEPPOL-EN16931-P0112 then limits them to invoices between two German parties; 326 on the British example reported that rule when tried.

How an integration ends up here

Possible causes, from the shape of the rule rather than from measured usage:

• The code table was built from the full UNTDID 1001 list, or from the EN 16931 subset, instead of the Peppol subset.
• Draft, proforma or quotation documents go through the same export as final invoices and keep their own type code.
• Self-billed invoices, coded 389, are sent through the ordinary Billing process.
• An internal document type number happens to be a valid UNTDID 1001 code with a different meaning.

How to fix it

1. Decide what the document is. If it is an ordinary claim for payment for goods or services, use 380.
2. For other kinds of invoice, pick the matching code from the Peppol list above, not from the full UNTDID 1001 list. If it is 326 or 384, check the German-parties condition as well.
3. If the document does not claim payment, as with a proforma, stop it being sent as a Peppol invoice rather than recoding it.
4. Restrict the code table in your mapping to the Peppol list, so an unsupported code is caught when the document is built.

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: a recognised Billing process with type code 325, proforma invoice

<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>
<cbc:DueDate>2026-10-08</cbc:DueDate>
<cbc:InvoiceTypeCode>325</cbc:InvoiceTypeCode>
<cbc:DocumentCurrencyCode>GBP</cbc:DocumentCurrencyCode>

Fragment of the corrected invoice: type code 380, commercial invoice

<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>
<cbc:DueDate>2026-10-08</cbc:DueDate>
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
<cbc:DocumentCurrencyCode>GBP</cbc:DocumentCurrencyCode>

Only cbc:InvoiceTypeCode differs: 325 in the failing invoice, 380 in the corrected one. The failing document reports only PEPPOL-EN16931-P0100; the EN 16931 layer passes because 325 is on the wider list that BR-CL-01 checks. The corrected value suits this example, which is an ordinary invoice; it is not a recipe for recoding a real proforma.

Where it applies

• Applies to UBL Invoice only. A CreditNote carries cbc:CreditNoteTypeCode, which PEPPOL-EN16931-P0101 checks against its own list.
• The same list applies under every recognised process identifier, including urn:peppol:bis:billing_with_response: 325 failed with that identifier too when tried.
• A code that is on neither list, such as 999, or an empty element, is reported here and by BR-CL-01 together.

Related rules

• BR-CL-01 checks the same element against the wider EN 16931 list
• PEPPOL-EN16931-P0101 applies the Peppol restriction to credit note type codes
• PEPPOL-EN16931-R007 must pass first, because this rule only runs for a recognised business process
• BR-04 reports a type code that is missing altogether
• 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-P0100 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.