BR-CL-01Use a permitted document type code

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.

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.

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: 999 is not a UNTDID 1001 invoice type code

<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

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

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
• BR-CL-23 checks unit codes on quantities against their code list
• BR-02 requires the invoice number, another mandatory header field
• Browse every rule in the reference

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-20.1: source checked 2026-09-20, explanation last updated 2026-09-20.

The official definition of 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.