# PEPPOL-EN16931-P0100: Use an invoice type code that Peppol BIS Billing allows
Peppol BIS Billing accepts only part of the UNTDID 1001 invoice codes. A code such as `325` (proforma) passes EN 16931 and fails here.
- Layer: Peppol BIS Billing
- Severity: fatal (the document is invalid)
- Topics: Code lists, Process and references
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/PEPPOL-EN16931-P0100/
- Explanation last updated: 2026-09-24
## 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.
| Term | Meaning | UBL element |
|---|---|---|
| BT-3 | Invoice type code | `cbc:InvoiceTypeCode` |
| 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 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.
## 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
```xml
urn:fdc:peppol.eu:2017:poacc:billing:01:1.0
EXAMPLE-INV-001
2026-09-08
2026-10-08
325
GBP
```
Fragment of the corrected invoice: type code 380, commercial invoice
```xml
urn:fdc:peppol.eu:2017:poacc:billing:01:1.0
EXAMPLE-INV-001
2026-09-08
2026-10-08
380
GBP
```
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.
### What the validator reported
- The failing invoice reports **PEPPOL-EN16931-P0100**. The corrected document passes every layer with no findings.
- [Download the failing XML](https://ironfang.uk/finance/rule-examples/PEPPOL-EN16931-P0100-invalid.xml)
- [Download the corrected XML](https://ironfang.uk/finance/rule-examples/invoice-minimal.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 `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](https://ironfang.uk/docs/finance/rules/BR-CL-01.md)
- [PEPPOL-EN16931-P0101 applies the Peppol restriction to credit note type codes](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-P0101.md)
- [PEPPOL-EN16931-R007 must pass first, because this rule only runs for a recognised business process](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R007.md)
- [BR-04 reports a type code that is missing altogether](https://ironfang.uk/docs/finance/rules/BR-04.md)
## 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](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/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.
## Links
- [This rule as a web page](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-P0100)
- [Free Peppol invoice validator](https://ironfang.uk/tools/peppol-validator)
- [Rule index](https://ironfang.uk/docs/finance/rules.md)
- [Ironfang Finance API docs](https://ironfang.uk/docs/finance)
- The same rule is available to MCP clients as the tool `finance.rule.get` on https://mcp.ironfang.uk/mcp