How to Match Customer Part Numbers and Units of Measure at Order Entry

When a wholesale customer sends an order, they use their own language: their part numbers, their pack descriptions, and the unit they buy in. Your enterprise resource planning (ERP) system speaks a different one, built from your internal item numbers and a single base unit of measure. The work that decides whether an order goes in clean is the translation between the two. Do it reliably and most lines post themselves; leave it to whoever opens the email and you rekey, guess, and occasionally ship the wrong pack.

The short answer is a maintained bridge, not a bigger inbox. Keep a cross-reference from each customer's part number to your SKU, store a conversion factor from the customer's ordering unit to your base unit, let only confident, exact matches post automatically, and route everything else to a named person before the ERP order is created. This article shows how to build that resolution step and where it should stop.

This is the layer beneath the channel question. Choosing EDI, an ERP import, or document extraction decides how an order arrives; it does not decide whether "AC1420, 5 cases" becomes the right 120 pieces of the right item. The subject here is the match itself.

See how incoming orders become reviewed ERP drafts.

Why the customer's part number is the real work

Business-to-business orders are built to carry more than one name for the same thing. An EDI 850 purchase order line can name an item by the buyer's part number, the vendor's part number, and a UPC at once, and it states the ordering unit of measure in the same line item, a case (CA) or an each (EA) for example, as the 850 purchase order reference describes. That is both a convenience and a trap: the buyer's part number is the one the customer trusts, and it is almost never your SKU.

Units carry the same ambiguity. Under GS1 standards, each packaging level, the each, the inner pack, and the case, is normally allocated its own unique Global Trade Item Number, as GS1 UK explains. A customer who simply orders "10" may mean ten eaches, ten inner packs, or ten cases, and each is a different quantity to pick, price, and ship.

The reassuring part is that resolving a customer's own number is a standard ERP feature, not a custom build. Oracle's JD Edwards documentation, for one, provides a customer item cross-reference for the case where customers order with their own part number during sales order entry, in its item cross-reference setup guide. Other systems use different names for the same idea. The task is less about buying software than about keeping that table current and deciding what happens when a line does not match.

A resolution ladder for every order line

Treat each order line as a small decision with four possible outcomes, ranked by how much certainty the match carries. This ladder is a decision method, not a benchmark or a guarantee; set the thresholds to your own catalog and error tolerance.

The point of the ladder is to make the confident cases free and the uncertain cases visible, rather than letting a single low-confidence guess flow silently into the ERP. A fuzzy match that is right nine times out of ten is still a wrong shipment on the tenth, so it belongs in review, not in the automatic lane.

Convert the unit before the quantity reaches the ERP

Store one base unit per item, usually the each, and a factor for every ordering unit the customer might use. The converted quantity, not the number the customer typed, is what should reach the ERP.

The following example is illustrative; the numbers are assumptions, not a client result. A customer orders on their own paper: "AC-1420, 5 CS." Your catalog holds SKU 88231 with a base unit of each and a case pack of 24. The cross-reference maps AC-1420 to 88231 exactly and the case factor is stored, so this line clears the top of the ladder: 5 cases × 24 each per case = 120 each, and the draft order shows 120 EA (or 5 CS carrying a factor of 24, if your ERP holds the case as a sellable unit). A second line reads "AC-1420-INR, 10," where the inner pack holds 6: 10 × 6 = 60 each. A third line reads "AC1420, 2" with no dash; that only matches after normalizing punctuation, so it drops to the review lane with 88231 shown as the likely candidate rather than posting on its own.

Two habits keep this honest. Keep the conversion factors on the item record, not in a spreadsheet a clerk edits by hand, and never convert a unit you cannot verify. A "pallet" whose count varies by customer is a review line, not a guess.

Who owns the held lines

A review lane is not an operating model until a person owns it. Name the role that resolves held lines, often a customer-service representative or the order-desk lead, and give the exceptions a service level so a held order does not age quietly past its ship date. Decide two things in advance: who can approve a new cross-reference entry so the fix sticks for the next order, and what the team does when the authoritative system, the ERP or the customer master, is unavailable and a match cannot be confirmed. Without those answers a smaller queue is not resolved work; it is the same work waiting.

Clean the master data before you automate

Matching only works against a catalog worth matching to. If your item master carries duplicate SKUs, retired numbers still flagged active, or missing pack factors, automation will process bad information faster. Conexiom, an order-automation vendor, reports from its own analysis of inbound purchase orders that part number, price, unit of measure, and ship-to were among the most common data-quality issues, in a post on order validation; that finding is the vendor's own and is not independently verified, but it matches what an order desk sees. Fix the cross-reference table, the active-item flags, and the unit factors first. Sometimes the right first project is that cleanup, not an extraction tool.

What to measure

Track three rates each week and keep them apart: the share of lines that post automatically, the share held for review, and the share a person had to correct after posting. A rising automatic-post rate is only good news if the correction rate does not rise with it. Report the hours the queue no longer needs as freed capacity, not as cash saved, because a lighter order desk is redeployed or absorbs growth long before it changes payroll. Measure against your own baseline, not a vendor's headline number, and you will know whether the bridge is holding.