Many order-entry queues mark every disagreement as a mismatch. That label tells the reviewer that something is wrong but not what decision has to be made. The operator still has to inspect the line, understand the field, and work out which records matter.
SKU, unit, and price mismatches should enter separate review paths. A SKU mismatch asks which product the customer meant. A unit mismatch asks how the quantity is measured. A price mismatch asks which commercial value the seller will honor.
1. One warning bucket hides the business decision
The three mismatches may appear on the same purchase-order line, but they are not interchangeable. Resolving the product can change the valid units and applicable customer price. Resolving the unit can change the effective quantity and line total. Accepting a price difference can require a reason or approval under the seller's policy.
The review interface should therefore name the affected field and show the evidence needed for that decision. A reviewer should not have to open a second system merely to learn why a line was flagged.
| Mismatch | Question to answer | Primary evidence |
|---|---|---|
| SKU | Which internal product did the customer order? | Customer part mapping, catalog code, description, order history |
| Unit | What does the ordered quantity represent? | PO unit, sellable unit, pack size, allowed conversions |
| Price | Which unit price should the seller use? | PO price, customer agreement, quotation, currency, effective date |
2. A SKU mismatch is a product-identification problem
A SKU mismatch occurs when the customer code or description does not resolve to one active internal catalog item. The source may contain a customer-specific part number, an old manufacturer code, a truncated code, or a description that fits several variants.
Show the source code and description beside a short list of plausible catalog records. Include the internal SKU, full description, sellable unit, and any customer-specific mapping. If one record is selected, preserve the source reference and record the mapping used for future review.
- Use an exact customer-part mapping before fuzzy description matching.
- Exclude inactive or unavailable items unless the reviewer can see why they appeared.
- Do not choose automatically when two variants remain plausible.
- Block approval until every required order line resolves to one item.
3. A unit mismatch changes the meaning of quantity
A unit mismatch appears when the purchase order uses a unit that differs from the catalog, price agreement, or allowed sales unit. Common examples include piece versus box, metre versus roll, kilogram versus pack, or a customer abbreviation that has no approved mapping.
Do not convert the quantity until the product is known and the conversion rule is explicit. One box may contain a different number of pieces for different SKUs. A conversion based only on the unit label can create a plausible but incorrect order.
| Step | Check | Result |
|---|---|---|
| 1 | Resolve the internal SKU | The valid sellable units become known |
| 2 | Compare the PO unit with allowed units | Exact matches can continue |
| 3 | Find a product-specific conversion | The effective quantity can be calculated |
| 4 | Recalculate price and line total | Commercial checks use the reviewed unit |
| 5 | Record the decision | The ERP receives an explainable quantity |
4. A price mismatch is a commercial decision
A readable PO price can still differ from the price the seller expects. The customer may be using an expired quotation, an old contract, the wrong currency, a price for another unit, or a value that includes a discount not represented in the product record.
Show the PO price beside the applicable customer price with the unit, currency, source, and effective date. The reviewer can then correct the order, accept the customer's price with a reason, or hold the order for commercial approval.
- Compare prices only after the SKU, unit, and currency are resolved.
- Show where the expected price came from and when it became effective.
- Recalculate the line total after any price decision.
- Require a reason when the reviewer accepts a material variance.
- Keep the buyer's original price as source evidence.
5. Resolve combined mismatches in dependency order
A line can contain all three mismatches at once. Handle them in the order that removes ambiguity: product first, unit second, price third. Reversing that sequence compares values before their meaning is settled.
After each decision, rerun the downstream checks. Selecting a different SKU changes the allowed units and customer price. Choosing a converted unit changes the effective quantity and can change the price basis.
| Order | Decision | Checks unlocked |
|---|---|---|
| 1 | Select the internal SKU | Valid units, pack sizes, product-specific price records |
| 2 | Confirm or convert the unit | Effective quantity and comparable unit price |
| 3 | Resolve the price | Reviewed line total |
| 4 | Recalculate totals | Order-level commercial and total checks |
| 5 | Save and approve | Controlled ERP handoff |
6. Put the decision evidence beside the editable line
Reviewers should not have to alternate between a PDF viewer, catalog search, pricing screen, and order form for every exception. Keep the source line visible beside the editable order line and show the matched customer, SKU, unit rules, and price record in the same review context.
The interface does not need to display every available field. It should expose the few values that explain why the line was flagged and what will change when the reviewer chooses an option.
7. Automate deterministic checks, not unresolved judgment
Some parts of the workflow have one repeatable answer: arithmetic, duplicate comparisons, exact customer-part mappings, allowed-unit checks, and total recalculation. Run those checks consistently and surface their results without asking a reviewer to reproduce them manually.
Ambiguous product selection and commercial exceptions still need a person. The system can rank candidates or show the expected price, but it should not hide uncertainty by turning the top candidate into an approved order line.
| Safe to calculate or enforce | Needs a reviewer when unresolved |
|---|---|
| Quantity × unit price and order totals | Which of several similar products the buyer intended |
| Exact duplicate customer and PO number | Whether a repeated document is a revision or duplicate |
| Exact approved customer-part mapping | Whether to create a new mapping from ambiguous text |
| Allowed units and known conversions | Whether an unusual unit should be accepted |
| Difference from the applicable price record | Whether the seller will honor the PO price |
8. Track the mismatch types separately
Separate categories make operational reporting useful. Repeated SKU mismatches may point to missing customer-part mappings. Unit mismatches may expose catalog or quotation problems. Price mismatches may reveal expired agreements or customers ordering from old documents.
Record the mismatch type, matched customer, final decision, and reason. Review the patterns by customer and product family. The goal is not to generate another dashboard. It is to fix the records and commercial processes that keep sending the same work back to the order desk.
- Count mismatches by type rather than one combined warning total.
- Separate corrected values from accepted exceptions.
- Review repeat causes by customer and product family.
- Update controlled mappings and records only after the decision is verified.
- Measure whether the same exception returns after the underlying record changes.
The queue should tell the reviewer what decision comes next
A useful review queue does more than flag a line. It distinguishes product identity, quantity meaning, and commercial agreement, then puts the relevant evidence beside each decision. That structure reduces unnecessary searching and makes the final order easier to audit.
Start by classifying exceptions in a representative batch of purchase orders. If most warnings still require the reviewer to diagnose the problem from scratch, the categories are too broad. The review path is ready when each exception names the field, the conflicting records, and the action required before ERP handoff.