AI Quantity Extraction: Validate Units Before Action

A delivery note says “12 cases,” while the receiving system expects individual items. An AI extractor returns 12. The number is legible and the JSON is valid, but accepting it could create the wrong stock movement.

Reliable AI quantity extraction preserves meaning before it normalizes numbers. The model can locate a quantity and its context; a controlled resolver should validate units and calculate permitted conversions. The process owner decides which interpretations may authorize action. Missing evidence should produce a held record, not an invented unit.

Define the quantity, not just the numeric field

In CQE: A Comprehensive Quantity Extractor, quantity extraction includes values, units and the concepts associated with them. That distinction matters operationally: “20 kg delivered” and “20 kg maximum load” contain the same number and unit but serve different decisions.

Bound the first implementation to one task, such as preparing received quantities for a warehouse work order. Supply the extractor with the permitted document, its revision and the relevant line-item context. Ask it to identify the quoted quantity, item and property—not to decide what the warehouse should book.

Keep these fields together in your application record:

• Evidence: source ID/revision, page or row, quoted span and related item identifier.
• Meaning: property being measured, such as delivered count, ordered mass or maximum capacity; requested, actual or limiting value.
• Expression: scalar, range, minimum, maximum or approximate quantity; preserve comparison operators and boundaries.
• Unit and basis: original unit text, approved unit identifier, packaging level and any evidence needed to resolve ambiguity.
• Resolution: normalized value only when justified, target unit, conversion or pack-size record/version, rounding policy and unresolved questions.
• Decision: validation result, responsible reviewer, accepted revision and downstream action receipt.

Keep the original representation alongside the normalized one. Research on product attribute extraction and normalization treats extracted and normalized values separately and includes unit conversion among normalization tasks. It does not establish that a particular model is accurate enough to release your operational records.

Separate three kinds of transformation

Unit conversion changes the scale, not the property

Converting a length from centimeters to meters preserves a length. A proposed conversion from liters to kilograms needs additional information about the material and relevant conditions; a unit dictionary alone cannot supply it. Validate that the source and target measure the same kind of quantity before calculating.

Use an approved, versioned conversion implementation rather than asking the model to improvise arithmetic. The NIST conversion-factor guidance explains factors, their use and rounding considerations. A business must separately choose its permitted units, precision and acceptance tolerances.

Packaging conversion needs item-specific evidence

A case is not a universal physical unit. Converting cases to individual items requires the applicable pack size for that item and transaction. “One case equals 24 items” may be valid for one SKU and wrong for another—or for an older packaging revision.

Resolve the pack size from a controlled record that actually applies to the order. Preserve its identity and effective version. If a supplier note and item master disagree, send the conflict to the item-data or receiving owner; do not let the model select the more convenient value.

Business interpretation changes what may happen

“Up to 10 cartons,” “about 10 cartons” and “10 cartons received” are not interchangeable. Preserve limits and approximation. Never turn an upper bound into an actual count or an approximate estimate into an exact commitment merely because the destination accepts only one number.

If the destination cannot represent the source meaning, hold the record for a policy decision or clarification. This is a focused control inside a broader AI data validation workflow, not a reason to weaken the source meaning to fit a field.

Use a quantity acceptance matrix

The following is a recommended application policy to adapt with your process owner. It is not an industry standard or a claim about a particular AI product.

Use deterministic schema and policy checks after extraction. Missing units, unknown identifiers, unsupported operators and invalid numeric output must remain visible. A model confidence value cannot establish a pack size or override an incompatible dimension.

Work through a case-to-item example

Illustrative scenario: a receiving clerk uploads a note for item A: “12 cases received; 2 cases damaged.” The receiving system stores individual items. The applicable order specifies 24 items per case, and the receiving policy requires damaged goods to remain separate from accepted goods.

1. Extract without collapsing the statements. Capture 12 cases as received and 2 cases as damaged, each bound to item A and its source span. Establish whether the damaged cases are included in the 12. If the document does not make that relationship clear, ask the receiving clerk before subtracting.
2. Confirm the basis. The clerk confirms that 2 of the 12 cases are damaged. Verify the order’s 24-items-per-case record applies to this delivery. The model’s general knowledge of packaging is irrelevant.
3. Calculate using rules. Total received is 12 × 24 = 288 items. Damaged is 2 × 24 = 48 items. The remaining 240 items are candidates for acceptance, not automatically accepted inventory.
4. Authorize the disposition. The designated receiving reviewer accepts or rejects the proposed disposition under the business policy. Store the quantities, pack-size evidence and decision together.
5. Verify the applied result. The authorized system writes the approved movement and reads back the outcome. Closure requires the expected item, quantities, disposition and accepted revision—not merely a successful model response.

A later correction to 20 items per case changes every derived count. Invalidate the earlier calculation and obtain a new decision. Do not overwrite evidence or reuse an old approval for a changed packaging basis.

Make holds and recovery part of the design

Assign each quantity exception to an owner with a follow-up target and explicit exit condition. The receiving clerk resolves source ambiguity; an item-data owner resolves packaging records; the process owner approves interpretation policy. If the assigned person is unavailable, escalate to a named backup rather than passing the quantity by default.

• Unreadable or malformed extraction: preserve the source and failure reason. A bounded retry may repair a technical parsing failure; an unreadable label needs a better source or human confirmation.
• Unsupported unit or unavailable resolver: keep the record held. Do not fall back to model-generated conversions as if they were equivalent validation.
• Reviewer rejection: return for corrected evidence or close as rejected, with a reason. An unanswered clarification is not approval.
• Changed source, item or policy: mark the old candidate superseded. Require checks against the current evidence before accepting a new revision; fence late callbacks from applying the old one.
• Destination timeout: keep the original action identity and reconcile through supported readback. An unknown outcome is not permission to submit another stock movement.

Persist an accepted quantity revision before dispatch. Bind the downstream operation to the work item, that revision and action type. Reuse its identity only within the destination’s actual idempotency contract. If readback cannot resolve an uncertain write, assign reconciliation and block further application. A genuine correction after confirmed application needs an authorized, linked adjustment—not a replay disguised as a retry.

Test the errors a numeric accuracy score misses

Build a labeled acceptance set with both extracted meaning and permitted business outcome. These are proposed tests, not reported results:

• Remove the unit: the output must expose missing evidence and stay held.
• Change “received” to “maximum”: the value may remain the same, but the field and action eligibility must change.
• Change a pack size from 24 to 20: derived counts must be recalculated and prior acceptance invalidated.
• Present incompatible dimensions: conversion must fail rather than manufacture a plausible number.
• Use a range, approximation and upper bound: each must retain its meaning instead of becoming a scalar.
• Deliver an old callback after correction: it must not apply the obsolete revision.
• Simulate a timeout after a successful write: reconciliation must find the existing result without duplicating it.

Test rounding at the business boundary too. If a minimum requires 2.01 units, rounding to 2 before checking the minimum can change the decision. Specify whether comparison uses the unrounded normalized value, what the destination can store and who resolves a precision mismatch.

Track correct value-plus-unit-plus-property extraction, unsupported conversion attempts, incorrect releases, false holds, clarification time and cost per verified completed record. Report by document type and quantity type; a good average can conceal failures on cases, ranges or ambiguous notation.

Where Workhint fits

The review layer needs required information and clear decision ownership. Workhint’s Workflow Engine describes requiring details, files, notes or approval steps before work moves forward, and routing approvals to defined roles. Those controls are relevant to collecting missing quantity evidence and assigning a reviewer.

The workflow automation software solution describes configuring forms, routing, tasks, roles and approvals around business processes. Use that as a basis for discussing the intake-to-review handoff. The extraction, unit resolver, packaging lookup and revision-safe destination write described here are application design requirements—not capabilities established by those marketing pages.

Start with the surrounding document extraction workflow, then define what quantity evidence a reviewer needs before releasing work. Keep the technical implementation and its tests explicit instead of assuming an approval screen proves the conversion is correct.

Frequently asked questions

Can the model convert units during extraction?

It can propose a normalized value, but that should not be the authority for an operational write. Preserve the source and independently validate the conversion with approved rules and applicable context.

Should missing units inherit the destination’s default?

Only when an explicit, applicable policy establishes that interpretation. Record the inference and its policy source. Otherwise ask for clarification; a destination default is not evidence of what the source meant.

Does a correct number mean the quantity is correct?

No. The item, property, unit, packaging basis and qualifier must also match. Twelve requested cases and twelve accepted items are different records even though both contain 12.

What is the safest first rollout?

Use one document type, a small approved unit set and a named reviewer. Run without downstream writes until the acceptance cases behave as intended. Release only the bounded action your process owner has authorized.