Source: PINT-AE BIS Invoice v1.0.2 Schematron

Rule at a Glance

ID Severity Context (XPath)
BR-23 Fatal (error) ubl:Invoice/cac:InvoiceLine / cac:CreditNoteLine
Schematron ID: ibr-023  |  Field: IBT-130 (Invoiced quantity unit of measure code)

Classification

Master Data / Transaction Data — BR-23 validates the unitCode attribute on the cbc:InvoicedQuantity (or cbc:CreditedQuantity) element at invoice line level. The quantity value (IBT-129) is checked by BR-22; this rule checks the unit dimension that gives that quantity its meaning. Both are required, and both are fatal if absent.

What the Rule Is Checking

BR-23 tests that the unitCode attribute exists on the cbc:InvoicedQuantity or cbc:CreditedQuantity element within every invoice line. In PINT-AE UBL 2.1, the quantity and its unit code travel together as attribute and value on the same XML element — <cbc:InvoicedQuantity unitCode="KGM">100</cbc:InvoicedQuantity>. Supplying a quantity without a unit code, or omitting the attribute entirely, triggers a fatal error.

The required unit codes come from the UNECE Recommendation 20 (Rec 20) code list. Common UAE trade codes include KGM (kilogram), MTR (metre), LTR (litre), PCE (piece), and DAY (day). For services where no physical unit applies, the code C62 (one / unit) is standard practice.

Why This Rule Exists

A quantity without a unit is arithmetically meaningless and legally incomplete. Under UAE VAT and Corporate Tax legislation, a tax invoice must identify the quantity and description of goods or services supplied. A line reading "100" with no unit code creates ambiguity the authority cannot resolve from structured data alone — and the PINT-AE standard requires machine-readable precision at every field. The unit code also drives downstream accounting and reconciliation: an ERP processing an inbound invoice needs to know whether it received 100 kilograms or 100 pieces before it can post the inventory or cost entry.

Standard / Code List

Unit codes are drawn from UNECE Recommendation 20. See the related post UNECE Rec 20 Unit Codes in PINT-AE for the UAE-relevant subset and common mapping errors. The code list is also published in the PINT-AE BIS v1.0.2 documentation under the UNECERec20 identifier.

UAE Data Example

PASSES ✓
<cbc:InvoicedQuantity unitCode="KGM">250.000</cbc:InvoicedQuantity>
<!-- 250 kilograms — unit code present and from Rec 20 -->

<cbc:InvoicedQuantity unitCode="C62">1</cbc:InvoicedQuantity>
<!-- 1 unit / one — correct code for service lines -->

FAILS ✗
<cbc:InvoicedQuantity>250.000</cbc:InvoicedQuantity>
<!-- unitCode attribute missing — BR-23 fatal error -->

<cbc:InvoicedQuantity unitCode="">250.000</cbc:InvoicedQuantity>
<!-- empty unitCode — still fails BR-23 -->

What Your ERP / IT Team Must Ensure

  • Every invoice line output from your ERP or billing system must include the unitCode attribute on the quantity element — not as a separate field, but as an XML attribute on cbc:InvoicedQuantity.
  • Your item master or service catalogue must carry a UNECE Rec 20 unit code for each item. Lines where the ERP unit of measure has no direct Rec 20 equivalent need a mapping table — this is a data governance task, not an IT task alone.
  • Service lines, consulting fees, and other non-physical supplies should map to C62 (unit/one). Using free-text descriptions in place of a code will trigger a fatal error.
  • Test the output XML for every item type in your catalogue — not just goods lines. Gaps in service-line unit code mapping are the most common BR-23 failure in practice.
  • For credit notes, the same rule applies to cbc:CreditedQuantity — the logic is identical, just on a different element name.

Related Rules

BR-22 (quantity value presence) · BR-24 (line net amount) · BR-25 (item name) · UNECE Rec 20 unit codes post