Each invoice line must have a unit of measure

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 unit was sent as a word: "pieces", "hours", "kg". The field takes a code.
• The line is a service with no natural unit and the field was omitted.
• The code is right but lowercase, or padded with spaces from a fixed-width source.

What to change

• For a countable item with no better unit, send C62, which is the code for "one" and is the correct answer for most lines on most invoices.
• For time, HUR is hours and DAY is days. For mass, KGM is kilograms.
• Map your internal unit names to codes in one place. Almost every occurrence of this failure is the same handful of words appearing on every line of every document.

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-23 usually breaks one of these too, because the same mapping gap tends to affect neighbouring fields.

• BR-22: line quantity

Questions people actually ask

What does BR-23 mean?

Every line says what its quantity is counted in, as a code from the UN/ECE Recommendation 20 list.

Which field does BR-23 apply to?

BT-130, Invoiced quantity unit of measure 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-23?

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.