Code lists — which values are permitted at all

A coded field is not a free-text field. The BR-CL family checks, for around two dozen fields, that the value sent comes from the list prescribed for that field.

23 rules · Rule set v2026-01-31

Where the lists come from

The lists are not part of the norm; the norm references them. UNTDID 1001 for the invoice type, UNTDID 4461 for payment means, UNTDID 5305 for the tax category, ISO 4217 for currencies, ISO 3166-1 for countries, UN/ECE Recommendation 20 for units of measure.

Which also means a code list can change without the norm changing. Hard-code the values in a mapping and you find out about a new edition when an invoice is rejected.

The cause underneath

Nearly every BR-CL failure arises the same way: the source system keeps the value as a house abbreviation — “pcs” for pieces, “INV” for invoice, “transfer” for the payment route — and the mapping passes it through unchanged. Translating it into the code is a table somebody has to build.

Build those tables once, centrally, rather than scattered per field. The three that fail most often are unit of measure (BT-130), invoice type (BT-3) and payment means (BT-81).

All code-list rules

With the official rule text, which names the list prescribed in each case.

NormAPI provides technical validation, not tax or legal advice.