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.

Peppol BIS BillingFatal: the document is invalidCode listsProcess and references

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

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.
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.
Derive the type code and the root element from the same source field, so the two cannot disagree.

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 credit note: the commercial invoice code 380 in a credit note

<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

<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 and PEPPOL-EN16931-P0101. The corrected document passes every layer with no findings.Download the failing XML Download the corrected 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.

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

Validate your corrected invoice Automate validation with the Ironfang Finance API