The invoice quantity is right and the match fails: unit-of-measure drift

The line reads 240 where the purchase order says 20, and nothing is wrong with either document. The order was placed in cartons and the supplier bills in eaches, at 12 to the carton. Extraction was accurate, the supplier is honest, the delivery was complete, and the match still failed — because the matching engine compared 2 numbers that were never expressed in the same unit.

This costs more than the exception itself. A buyer is pulled into a supplier query that has no answer, the supplier is asked to explain a variance that does not exist, and the same line fails again next month because nothing structural changed. Unit drift is one of the few AP exception types that reproduces perfectly on a schedule.

Divide the invoiced quantity by the ordered quantity

The confirming check takes seconds per line and can be run over an entire quarter of failures at once. Two numbers decide it: the quantity ratio, and whether the extended amounts agree.

1. Compute the ratio of invoiced quantity to ordered quantity for every line that failed on quantity in the last 90 days.
2. Round to 4 decimal places and count the distinct values. Conversion problems collapse into a handful of repeated numbers — 6, 12, 24, 144, 0.0833 — while genuine variances scatter.
3. Compare the extended amounts on the same lines. If the invoice line total equals the ordered line total while the quantities differ, unit price and quantity moved together and the unit is the only difference.
4. Group the clean-ratio lines by supplier and item. Almost always a small number of suppliers, and often a single item family within each.
5. Check the receipt quantity in the same unit before concluding. If the receipt agrees with the invoice and disagrees with the order, the order was raised in the wrong unit rather than the invoice being billed in it.
6. Send everything that survives both tests to a person. An irregular ratio with a larger extended amount is a real variance and needs a buyer, not a conversion factor.

Four ways a unit changes between the order and the invoice

Each has a different structural fix, and only the first is solved by a static conversion factor. Ranking them by volume in most AP populations puts pack-size conversion far ahead of everything else.

The conversion record, and where it has to live

A factor buried in a matching rule is a bug waiting to happen. It belongs on the supplier-item relationship as data, with an owner, a history and an effective period, because the thing it describes genuinely changes: suppliers reconfigure packs, contracts renegotiate, and a factor applied retrospectively to old receipts will silently misvalue them.

• Supplier and supplier item code. Your own item code is not enough — 2 suppliers of the same product may pack it differently.
• Ordering unit, receiving unit and billing unit as 3 separate fields. Warehouses frequently receive in a third unit that matches neither document.
• The factor, with direction stated explicitly. Half of all conversion defects are an inverted factor that looked plausible in testing.
• Effective from and effective to dates, applied against the delivery date rather than the invoice date, so a late invoice for an old delivery still converts correctly.
• Source and owner. Who asserted this factor, from which document, and who may change it — the same discipline the rest of the supplier master record fields needs.

Unit strings themselves deserve one rule: never match on them directly. Supplier documents carry free text — EA, EACH, CS, CT, BX, PK — and the same abbreviation means different things to different suppliers. Map every incoming string to a controlled internal unit at capture, using the international unit-of-measure code list that most e-invoicing and EDI schemas already reference, and confirm the current list at its source rather than trusting a hard-coded table. The mapping is part of the ingestion path, alongside everything else covered in building the mailbox-to-invoice pipeline.

Catch weight: when there is no constant factor

Food, metals and some chemicals are ordered by count and supplied by weight. A case of cheese ordered as 1 case weighs what it weighs, and the invoice bills the actual kilograms. There is no factor that reconciles 1 to 18.4, and forcing one produces either constant exceptions or a tolerance so wide it stops checking anything.

• Match on weight, not count, for these item families, and mark them so the engine knows which rule to apply.
• Capture actual weight at goods receipt. Without it there is nothing to match the invoice against, and the check degenerates into trusting the supplier.
• Set the tolerance against nominal weight per pack, not against the order line. A 5% band on a nominal 18 kg case is meaningful; the same band on a 40-case order hides a whole missing case.
• Price per kilogram must be compared in the same unit as the quantity, which is a separate check from the quantity one — the boundary drawn in what a matching engine is allowed to wave through.

Telling a conversion error from genuine over-supply

The 2 diagnoses look identical on the exception screen and lead to opposite actions, so the distinction is worth stating precisely. A conversion error means the documents describe the same delivery in different units: the ratio is stable, the extended amounts agree, and the receipt corroborates one of the 2 quantities exactly. Over-supply means more goods arrived or were billed than were ordered: the ratio is irregular, the invoice total exceeds the order total proportionally, and the receipt agrees with the invoice.

One case sits between them and catches people out. A supplier who ships a full case against a part-case order has both over-supplied and used a different unit, so the ratio looks clean while the money genuinely differs. The extended-amount test separates it: the totals do not agree, and the difference is exactly the value of the extra units.

Clearing the backlog this has already created

1. Run the ratio and extended-amount tests over every open quantity exception. Expect a large share to resolve without a supplier conversation.
2. Write conversion records for the suppliers and items that repeat, effective from the earliest delivery date in the backlog.
3. Re-run matching over the affected lines rather than editing them by hand, so the audit trail shows a rule applied and not a person overriding a control.
4. Separate the residue into real variances and receipt problems. A quantity exception where no receipt exists at all is a different diagnosis — matching that fails because the goods receipt has not been posted yet.
5. Fix the corrections you already issued. Credit notes raised for phantom over-billing have to be tied back to the original transaction, and that identity problem is its own trap — see refunds that never find their original capture.

Unit drift is a data-modelling problem wearing an exception's clothes, and it responds to a small amount of structure: 1 conversion record, applied before matching, owned by someone. That is the kind of layer we build over an existing ERP for finance teams across fintech and financial operations, usually as AI agents and workflow automation around the matching engine rather than a replacement for it. The rest of the invoice-to-pay and AP automation cluster covers the matching, tolerance and queue design it sits inside, and choosing an AI development partner covers what to ask whoever builds it.

• invoice matching
• unit of measure
• accounts payable
• supplier data