BR-CL-08: Put an upper-case UNTDID 4451 subject code between the hashes of an invoice note

The short answer

BR-CL-08 fails when an invoice-level cbc:Note has exactly three characters between its first and second #, and those three are not found in the UNTDID 4451 list. The recorded note began #aai#; the codes are upper case, so the corrected note begins #AAI#, General information.

In UBL the note subject code (BT-21) travels inside the note text in this #CODE# form. A note that is not meant to carry a subject code must not happen to contain three characters between two hashes either.

What the rule checks

The rule reads each cbc:Note directly under the root and takes the text between its first two # characters. Only when that text is exactly three characters long is it looked up; otherwise the note passes. When tried, #INFO# with four letters and a note with a single # both passed.

The code does not have to open the note. When tried, Please quote #XYZ# when you pay failed, and so did Order #123# delivered in full, because 123 sits between two hashes.

Nothing is trimmed or folded to upper case. When tried, #aai# failed, and so did the invented #INF#. The lookup searches the list as one string of codes separated by spaces, so three characters that include a space can pass: #A A# did when tried.

Line notes are outside the rule. When tried, #aai# at the start of a line cbc:Note passed.

How an integration ends up here

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

• A template writes the subject code in lower case, as in the recorded example.
• The integration makes up a code from a word, such as #INF# for information or #VAT# for a tax remark, instead of taking one from the list.
• Free text typed by the seller contains a reference between hashes, such as an order number, with exactly three characters in the first pair.

How to fix it

1. Decide whether the note needs a subject code at all; a note without one is valid.
2. If it does, take the code from UNTDID 4451 and write it in upper case between two hashes at the very start of the note, then the text: #AAI# for General information.
3. If free text can contain #, replace the character before writing the note, or put a real subject code first so that the first pair of hashes always holds it.
4. Offer the subject codes your system uses as a fixed choice, checked against the list, rather than letting users type them.

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: the note subject code is written in lower case

<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
<cbc:Note>#aai#Please quote the invoice number when you pay</cbc:Note>
<cbc:DocumentCurrencyCode>GBP</cbc:DocumentCurrencyCode>

Fragment of the corrected invoice: the subject code is AAI, General information

<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
<cbc:Note>#AAI#Please quote the invoice number when you pay</cbc:Note>
<cbc:DocumentCurrencyCode>GBP</cbc:DocumentCurrencyCode>

Only the case of the subject code differs: #aai# in the failing invoice, #AAI# in the corrected one, with the same text after it. The failing document reports BR-CL-08 alone, and the Peppol layer passed.

Where it applies

• Applies to Invoice and CreditNote; #aai# at the start of a credit note cbc:Note reported this rule alone when tried.
• The Peppol layer does not look at subject codes, but it limits the number of notes: unless seller and buyer are both German, a second cbc:Note is reported by PEPPOL-EN16931-R002. When tried, two notes, the second beginning #aai#, reported both rules.
• The pinned list has 383 codes. Check a code against the list of this release rather than an older copy of UNTDID 4451.

Related rules

• PEPPOL-EN16931-R002 allows only one invoice note outside German domestic trade
• PEPPOL-EN16931-CL003 rejects a note subject code such as DEL when it is reused as a charge reason code
• Browse every rule in the reference
• Background: Understanding EN 16931 validation errors

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

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