Rule BR-CL-01
The document type code must come from UNTDID 1001
The code saying what kind of document this is must be one of the values UNTDID 1001 defines for invoices and credit notes, not a label of your own.
Business term BT-3, Invoice type code. Source: EN 16931. Our wording, not the normative text, which is published in the Peppol BIS Billing 3.0 rule list (EN 16931 rules) and was checked against it on 2026-08-16.
Why it fires on invoices that look fine
Almost nobody hits this rule because they forgot the field exists. They hit it because something between their system and the document dropped it, changed its shape, or filled it with a value that is right somewhere else. These are the causes worth checking first.
- The field carries an internal document type instead of the standard code: "INV", "FACTURE", "SalesInvoice" or a numeric key from your own document table. All four are readable and none of them is on the list.
- A credit note is sent with the invoice code 380 still in place, usually because the credit note is built by copying the invoice record and negating the amounts. The correct code is 381, and getting it wrong misfiles the document at the receiver rather than rejecting it outright.
- The right code is there but padded or typed: "0380", " 380" or the number 380 serialised as an integer where the receiver expects a string.
- A code exists in UNTDID 1001 but not in the subset EN 16931 allows. The parent list is much longer than the invoicing profile, so a code being real is not the same as it being accepted.
What to change
- Use 380 for a commercial invoice and 381 for a credit note. Those two cover almost every document a supplier sends, and picking either correctly is most of this rule.
- Map your internal document types to the standard codes once, in the export layer, rather than hoping the two vocabularies happen to coincide. They will not.
- Send the code as a string of exactly the digits, with no leading zeros and no surrounding whitespace, and validate it against your list before it leaves.
- If you genuinely need one of the rarer codes, such as 384 for a corrected invoice, check it against the EN 16931 subset rather than the full UNTDID list, because they are not the same set.
The validator runs in your browser. Nothing is uploaded, and you can confirm that yourself with the network panel open.
Rules you are likely to hit next
A document that breaks BR-CL-01 usually breaks one of these too, because the same mapping gap tends to affect neighbouring fields.
Questions people actually ask
- What does BR-CL-01 mean?
- The code saying what kind of document this is must be one of the values UNTDID 1001 defines for invoices and credit notes, not a label of your own.
- Which field does BR-CL-01 apply to?
- BT-3, Invoice type code. That is the name the semantic model uses, which is what you search for in your own system's mapping when the identifier alone does not tell you which field to look at.
- Does our validator check BR-CL-01?
- Yes. Paste your invoice data into the free validator and it reports this rule with the value it actually saw, without the document leaving your browser.