Matching SKUs from a customer purchase order to Shopify means mapping each PO line, often a buyer’s code or a loose product name, to the correct product and variant in your store. A sound workflow auto-matches confident lines, flags uncertain ones, applies your catalog prices, and only then creates a draft order. Wrong variants should not ship because a title looked close.
Why the buyer’s SKU is not your SKU
Their purchasing system has its own item master. You will see customer-specific codes, last year’s catalog numbers, and pack language (“case of 12”) next to a sellable unit you stock as one variant. Two colors with nearly the same title will both look like a match. The expensive failure is the quiet one: the draft looks complete, and the warehouse picks the wrong size.
What manual matching actually is
Someone keeps a spreadsheet. VLOOKUP if they are disciplined. A notes doc if they are not. The real index is tribal: one ops person who remembers that Account 14’s “NX-200” is your SKU “HAT-NVY-L”. When that person is out, the Monday POs wait, or they get guessed.
What good enough looks like
- A confident line, an exact SKU or a known customer-specific SKU, can attach without a debate.
- An uncertain line stops. A human picks the variant.
- Nothing low-confidence becomes a draft line in silence.
POinbox flags unmatched or uncertain lines before the draft is created.
How POinbox helps
It maps PO lines to products and to customer-specific SKUs, using your Shopify catalog. A barcode on the line matches the barcode on the variant. A buyer code stored on the product as a metafield can match too. If this customer has ordered the item before, that past Shopify order can attach the same variant. Flags show up before create. The file still has to get in: PDF or email.
Confirm a line and that buyer’s code is saved for that customer or company. The next PO with the same code uses the variant you already approved. Confirm the buyer and the sender is saved to that company for the next email. Buyer codes, senders, and unit conversions live together under Mappings.
POinbox starts free (5 successful drafts). Paid plans from $29/mo. How the match is supposed to behave is on the product page.
Prices while you are matching
A matched SKU can still have the wrong money. The PO says $18. Your catalog says $21. Matching the item does not mean accepting their price. Flag PO vs catalog price differences.
Pack and case language
Buyers write “2 cases.” You sell eaches. POinbox converts case, pack, carton, and dozen when a mapping is saved, and it can read the multiplier from the pack size or the variant title. Set that once under Mappings. A unit it cannot place stays on the line for you.
Hygiene on your side
- Keep Shopify SKUs unique and current. A duplicate SKU makes every matcher, human or app, guess.
- Confirm a buyer code once in the app. That mapping is what the next PO from that customer uses.
If the goal is less typing overall, the wider page is automate B2B order entry.
A line that should not auto-match
The PO says “Navy cap” and a buyer code you have never stored. Your catalog has Navy cap S, M, and L, plus a Navy cap in a second fabric. A matcher that picks L because it is the first result has created a return. The correct behavior is a flag: here are the candidates, a person picks, the draft does not exist yet.
A line that can auto-match is duller and better. The buyer code is already the Shopify SKU, or it is a code you confirmed last time for that customer. POinbox uses that saved match on the next order.
Quantity is part of the match. “2 CS” becomes eaches when a case mapping is saved, or when the pack size or variant title already says how many are in the case. Open the line and read the quantity before you accept it. A perfect SKU with a wrong quantity still ships the wrong order.
Do this hygiene before you blame the app: one SKU per variant, no duplicate SKUs, retired codes archived instead of reused. A duplicate SKU makes every tool guess.
Where a confirmed code lives
Confirm the line in POinbox and that buyer’s code is stored against the variant, for that customer or company. Next month the same code comes back already matched. A sheet still helps when someone outside the app needs the decision: buyer, their code, your variant, who confirmed it, and the date. Matching itself uses the saved mapping.
Retire codes that now mean a different variant. Reusing a SKU is how last year’s alias becomes this year’s wrong size. That cleanup is yours. No PO app fixes a catalog that contradicts itself.