# BR-CL-01: Use a permitted document type code

cbc:InvoiceTypeCode and cbc:CreditNoteTypeCode must hold a UNTDID 1001 code from the list for that document, such as 380 or 381.

- Layer: EN 16931
- Severity: fatal (the document is invalid)
- Topics: Code lists, Core fields
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-CL-01/
- Explanation last updated: 2026-09-20

## The short answer

`BR-CL-01` fails when the document type code is not in the UNTDID 1001 subset that EN 16931 allows for that kind of document. Send the code that describes what the document is: `380` for a commercial invoice in `cbc:InvoiceTypeCode`, `381` for a credit note in `cbc:CreditNoteTypeCode`, or another listed code where it genuinely applies.

There are two lists, one per element. A code from the credit note list inside an `Invoice`, or the reverse, fails even though the code itself is a real UNTDID 1001 value.

## What the rule checks

The rule runs on `cbc:InvoiceTypeCode` and on `cbc:CreditNoteTypeCode`, and tests each against its own list: invoice-type codes for the first, credit-note-type codes for the second. `381` in an `Invoice` fails, and so does `380` in a `CreditNote`.

White space around the value is ignored; `380` padded with spaces passes. Otherwise the match is exact and on a single code, so `0380` and `380 380` fail.

An empty element fails this rule and is also reported by `BR-04`, the Peppol type code rule and `PEPPOL-EN16931-R008`. A document with no type code element at all does not reach this rule: UBL makes the element optional, so the XSD layer passes, and `BR-04` reports the missing code.

Peppol narrows the choice further. `PEPPOL-EN16931-P0100` for invoices and `PEPPOL-EN16931-P0101` for credit notes accept only part of the EN 16931 list, so a code can pass `BR-CL-01` and still fail on the Peppol layer: `130` and `202` do in an `Invoice`, and `261` does in a `CreditNote`. Going the other way, `999`, `0380` and a `381` placed in an `Invoice` fail on both layers.

| Term | Meaning | UBL element |
|---|---|---|
| BT-3 | Invoice type code | `cbc:InvoiceTypeCode (Invoice) or cbc:CreditNoteTypeCode (CreditNote)` |

## How an integration ends up here

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

- An internal document type, such as `INV`, `1` or a ledger code, is written to the element without translation.
- The source system models credit notes as invoices with a different type, and the mapping puts `381` into an `Invoice` root.
- The code was taken from the full UNTDID 1001 list, which also covers orders, despatch advice and other documents that are not invoices, for example `220`.
- The value is formatted as a number with padding, giving `0380`.
- A default was never set and the builder emits an empty element.

## How to fix it

1. Decide what the document is in business terms first: invoice, credit note, corrected invoice, prepayment invoice and so on. The code follows from that; it is not a free choice.
2. Translate the internal type to a code in an explicit table, and restrict the table to codes that pass both `BR-CL-01` and the Peppol rule for the root element you send.
3. If the document is a credit note, build a `CreditNote` with `cbc:CreditNoteTypeCode`. That is a different root element with its own line and quantity names, not a code swapped inside an `Invoice`. Do not relabel a credit note as `380` to clear the error.
4. Emit the code as a plain string with no padding or leading zeros.

## Before and after

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

Fragment of the failing invoice: 999 is not a UNTDID 1001 invoice type code

```xml
<cbc:IssueDate>2026-09-08</cbc:IssueDate>
<cbc:DueDate>2026-10-08</cbc:DueDate>
<cbc:InvoiceTypeCode>999</cbc:InvoiceTypeCode>
<cbc:DocumentCurrencyCode>GBP</cbc:DocumentCurrencyCode>
```

Fragment of the corrected invoice: 380, commercial invoice

```xml
<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: `999` in the failing file, `380` in the corrected one. The failing document also reports `PEPPOL-EN16931-P0100`, the Peppol restriction on invoice type codes: Peppol permits fewer codes than EN 16931, and `999` is on neither list. One finding comes from each layer for the same element, and a code that Peppol accepts clears both.

### What the validator reported

- The failing invoice reports **BR-CL-01** and [PEPPOL-EN16931-P0100](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-P0100.md). The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/BR-CL-01-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` through `cbc:InvoiceTypeCode` and to `CreditNote` through `cbc:CreditNoteTypeCode`, with a different list for each. A `CreditNote` with `999` or `380` reports `BR-CL-01` together with `PEPPOL-EN16931-P0101`.
- Some codes carry further Peppol conditions beyond the two lists. `384` on the British test invoice passes `BR-CL-01` and `PEPPOL-EN16931-P0100` and reports `PEPPOL-EN16931-P0112`.
- The lists are those pinned in the EN 16931 1.3.16 and Peppol BIS Billing 3.0.21 artefacts. Check the Peppol code list for the release you target instead of relying on the wider EN 16931 one.

## Related rules

- [BR-CL-04 is the code list check for the document currency, the next header element](https://ironfang.uk/docs/finance/rules/BR-CL-04.md)
- [BR-CL-23 checks unit codes on quantities against their code list](https://ironfang.uk/docs/finance/rules/BR-CL-23.md)
- [BR-02 requires the invoice number, another mandatory header field](https://ironfang.uk/docs/finance/rules/BR-02.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-20.

[The official definition of BR-CL-01](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-CL-01/) 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/BR-CL-01)
- [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