# PEPPOL-EN16931-P0101: Use a credit note type code that Peppol BIS Billing allows

In a Peppol credit note, `cbc:CreditNoteTypeCode` must be `381`, `396`, `81`, `83` or `532`. An invoice code such as `380` is rejected.

- 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-P0101/
- Explanation last updated: 2026-09-24

## The short answer

`PEPPOL-EN16931-P0101` fails when the `cbc:CreditNoteTypeCode` of a `CreditNote` is not one of the five codes Peppol BIS Billing allows for credit notes. For an ordinary credit note, write `381`.

An invoice code inside a credit note, like the `380` in the recorded example, also fails the EN 16931 code list check `BR-CL-01`. If the document really is an invoice, build an `Invoice` document rather than changing the code.

## What the rule checks

The rule reads `cbc:CreditNoteTypeCode`, trims surrounding spaces and accepts exactly `381` (credit note), `396` (factored credit note), `81` (credit note related to goods or services), `83` (credit note related to financial adjustments) and `532` (forwarder's credit note).

EN 16931 permits more credit note codes than Peppol. `261` passed `BR-CL-01` and failed this rule alone when tried.

A code from the invoice side of UNTDID 1001 fails both lists. `380`, `383` and `384` in a credit note each reported this rule together with `BR-CL-01` when tried.

Like its invoice counterpart, the rule runs only for a recognised business process identifier. A credit note carrying `380` under an unrecognised `cbc:ProfileID` reported `BR-CL-01` and `PEPPOL-EN16931-R007`, but not this rule.

| Term | Meaning | UBL element |
|---|---|---|
| BT-3 | Invoice type code | `cbc:CreditNoteTypeCode` |
| 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:

- One type code field serves both documents in the source system and holds `380` for everything, while the root element is chosen from the sign of the total.
- A corrected invoice (`384`) or a debit note (`383`) is issued as a `CreditNote` because its amounts are negative.
- The code table for credit notes was copied from the EN 16931 list rather than the Peppol subset.

## How to fix it

1. Confirm the document is a credit note, one that reduces or cancels an amount previously invoiced. If so, keep the `CreditNote` root and use `381`, or `396`, `81`, `83` or `532` where one of those describes it better.
2. If the source says the document is an invoice, generate an `Invoice` with `cbc:InvoiceTypeCode` instead. The line and quantity elements have different names in the two documents, so this is a different output, not a renamed root.
3. Derive the type code and the root element from the same source field, so the two cannot disagree.

## Before and after

These are fragments, not complete documents. The complete synthetic documents they come from are linked below.

Fragment of the failing credit note: the commercial invoice code 380 in a credit note

```xml
<cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>
<cbc:ID>EXAMPLE-CN-001</cbc:ID>
<cbc:IssueDate>2026-09-08</cbc:IssueDate>
<cbc:CreditNoteTypeCode>380</cbc:CreditNoteTypeCode>
<cbc:DocumentCurrencyCode>GBP</cbc:DocumentCurrencyCode>
```

Fragment of the corrected credit note: 381, credit note

```xml
<cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>
<cbc:ID>EXAMPLE-CN-001</cbc:ID>
<cbc:IssueDate>2026-09-08</cbc:IssueDate>
<cbc:CreditNoteTypeCode>381</cbc:CreditNoteTypeCode>
<cbc:DocumentCurrencyCode>GBP</cbc:DocumentCurrencyCode>
```

Only `cbc:CreditNoteTypeCode` differs: `380` in the failing credit note, `381` in the corrected one. The failing document also reports `BR-CL-01` from the EN 16931 layer, because `380` is not a credit note code in EN 16931 either. One wrong value produces a finding in each layer, and `381` clears both.

### What the validator reported

- The failing credit note reports [BR-CL-01](https://ironfang.uk/docs/finance/rules/BR-CL-01.md) and **PEPPOL-EN16931-P0101**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/PEPPOL-EN16931-P0101-invalid.xml)
  - [Download the corrected XML](https://ironfang.uk/finance/rule-examples/credit_note-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 `CreditNote` only. The invoice type code is checked by `PEPPOL-EN16931-P0100` against a different list.
- The five codes apply under every recognised process identifier; `261` failed under `urn:peppol:bis:billing_with_response` as well when tried.
- An empty `cbc:CreditNoteTypeCode` reported this rule together with `BR-04`, `BR-CL-01` and `PEPPOL-EN16931-R008` when tried.

## Related rules

- [BR-CL-01 checks the credit note type code against the EN 16931 list and fires with this rule for invoice codes](https://ironfang.uk/docs/finance/rules/BR-CL-01.md)
- [PEPPOL-EN16931-P0100 is the same Peppol restriction for invoice type codes](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-P0100.md)
- [PEPPOL-EN16931-R007 checks the business process identifier this rule depends on](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R007.md)
- [BR-04 reports a credit note with no type code at all](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-P0101](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/PEPPOL-EN16931-P0101/) 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-P0101)
- [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