unit of measure misread on invoice lines (EA vs CA)

TL;DR

Units like EA (each) and CA (case) are two-letter codes that OCR confuses, and the wrong unit changes what the quantity means. Resolve UOM against the purchase order line, which carries the authoritative unit; when there is no PO, validate against the vendor's catalog or history. Never let a UOM mismatch silently pass into receiving.

Error

Extracted UOM: CA (case); PO line UOM: EA (each); quantity 100 now ambiguous

Steps

1. Extract the UOM token from each line item. Expected: Raw UOM strings.

2. Normalize against a standard UOM list (EA, CA, BX, PK, KG, L, M). Expected: Canonical units.

3. Compare with the PO line UOM for matched lines. Expected: Agreement or a flagged mismatch.

4. On mismatch, scale-check: does quantity times unit price still reconcile? Expected: Math catches unit errors that change value.

5. Flag unresolved mismatches for the buyer to confirm. Expected: The person who ordered knows the unit.

When to use

• UOM present on invoice lines
• PO matching with unit-sensitive goods
• Quantity-times-price reconciliation fails

When not to use

• Service invoices with no units
• PO quantity mismatches unrelated to units
• Weight vs count conversions (needs conversion tables)

Compatibility

Extractor-agnostic; needs PO line data from the ERP or procurement system.

Variant phrasings

UOM misread invoice

EA vs CA unit confusion

unit of measure extraction

Root cause

UOM codes are short, uppercase, and often abbreviated inconsistently by vendors. Two-letter codes with similar shapes (EA/CA, PK/PC) are exactly the shapes OCR confuses, and vendors do not standardize them.

Edge cases

• Vendor-specific UOM codes need a per-vendor mapping table
• Catch-weight items (KG) vary per delivery; tolerance must be wider
• Some invoices omit UOM entirely; inherit from PO by policy, flagged

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_uxvZ4gefCpuw9rwfCXRCFw