Customer part number to our SKU
The cross-reference problem behind every RFQ and PO. Lookup tables, attribute matching, revisions, UoM, MOQ, contract price, the exception card, and writing to the ERP without duplicates.
- KKK Manoj KumarCo-founder
5 min read
Every PO that reaches an order desk is written in the customer's language. Their part number, their description, their unit, and their price from whichever contract they think is current. Before anything can be keyed, someone has to translate each line into yours: your SKU, your revision, your unit, your price. On most desks that translation lives in a cross-reference sheet, a few years of email, and the memory of whoever has looked after that customer longest.
That translation is most of the work in order entry, and it's where automated order entry usually goes wrong. Reading the PDF is the easy part now. Microsoft ships a Sales Order Agent for Dynamics 365 that watches a mailbox and creates sales orders from PDF and image POs (Sikich, February 2026), and a Distribution Strategy Group survey from February 2026 found order automation was the most common AI use among scaling distributors, at 62%. The hard part is the lookup, and what happens when the lookup isn't clean.
The cross-reference is the system
Start with the table you already have. Most desks keep a customer-part-to-SKU mapping somewhere, even if it's a tab in one person's workbook. An exact hit on customer, customer part number and revision is the best evidence you'll ever get, so the agent checks it first and trusts it most.
When there's no exact hit, the agent falls back to the description. "Impeller, 180 mm, CF8M, 6 mm keyway" can be matched against your item master the same way a BOQ line is matched against a catalogue: pull out the attributes, filter on the ones that decide the part, score the rest, and propose a SKU with its reasons. A line matched this way is a proposal, and it goes to a person the first time. When they confirm it, the pair is written back to the cross-reference, so the next PO from that customer hits exactly. Over a few months the table fills in, and you can see why fewer lines need a person.
Watch for one customer part number that means two things. It happens when the customer's own item master has been renumbered, or when two of their plants buy under one code with different specs. The agent has to read customer and ship-to together, and when one customer part maps to more than one of your SKUs, it asks.
What gets checked after the match
A mapped SKU is where the checks start. Each line then goes through the questions a careful CSR asks:
- The customer orders rev C and you now make rev D. Sometimes that's fine, and sometimes rev C was retired for a reason, so the agent flags it and never picks one silently.
- The PO says 10 boxes and you sell in pieces, 50 to a box. Conversions come from the item master, and a line with no known conversion stops.
- 130 pieces against a pack of 50 is either a rounding question or a deliberate order, and the customer should say which.
- The PO price is compared with the contract or price list in force on the PO date, quantity breaks included. A price below contract goes to a person, and so does a price above it, because that usually means the customer is working from an old quote and will dispute the invoice.
- The ship-to must match the customer master, and the requested date is checked against available-to-promise.
All of that ends in one exception card for the person who owns the account, showing only what's wrong:
PO 4500-7731 · customer C-1042 · received 09:12 by email (PDF, 2 pages)
Lines 7 · 6 clean · 1 exception
Line 3 Cust part 44-1180 rev C → VS-IMP-1180 (current rev D) revision mismatch
PO price ₹1,240.00 · contract ₹1,265.00 (−2.0%) below contract
Ship-to Chakan plant, matches customer master ok
Date requested 12 Nov · ATP 14 Nov 2-day slip
[ Approve 6 lines ] [ Hold line 3 ] [ Draft email to buyer ]The six clean lines go through with one click. Line 3 waits, with the email to the buyer already drafted.
Writing to the ERP without breaking it
Once a person approves, the order has to land in the ERP, and it should come in through the same door a person uses. In SAP that means the standard sales order API, so pricing conditions, credit checks and availability run exactly as they do when a CSR keys the order. Zoho Books has a sales order endpoint that takes the India GST fields, GSTIN, place of supply and HSN or SAC on each line, and an order written without them will fail at invoicing instead of now. TallyPrime takes XML over its HTTP server, usually on port 9000. It's synchronous and has no webhooks, so the agent reads back to confirm the voucher was created. When the ERP rejects an order, the rejection goes to the person with the ERP's own message, and the agent doesn't look for a way around it.
We roll this out in three steps: read-only first, then drafts a person posts, then posting clean orders directly. Each runs long enough to show its exception rate.
The failure that hurts most is the duplicate. The ERP times out after creating the order, the agent retries, and now there are two sales orders for one PO, and two dispatches if nobody notices. People building order automations keep describing this exact bug (r/n8n). The fix is an idempotency key. Each order write carries a key built from the customer, the PO number and the PO revision, and before writing, the agent checks whether an order with that key already exists. If one does, it reports that order number and writes nothing.
The same check catches the human version, when a customer sends one PO to two inboxes or a revised PO under the same number. A PO number already on file is treated as an amendment until a person says it's a new order, and the agent shows the difference against the existing order line by line.
To size the job, take the cross-reference you have, however messy, and the last three months of POs. Run them through matching only, with no writes, and count how many lines hit the table exactly, how many matched on attributes, and how many found nothing. That split tells you how much of the work is the agent's and how much is the item master's, before anyone touches the ERP. It's also the first week of our quote-to-order work.