## 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

```text
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