Supplier SKUs vs your SKUs on Shopify purchase orders

Every small retailer has the spreadsheet. Column A is your SKU, column B is what the supplier calls the same thing, column C is the last price they charged, and column D is a note like “min 12” or “ships in cases of 6”. It lives on one person's laptop, it was last updated in spring, and the purchase order you are about to send has to be checked against it line by line before the supplier will accept it without a phone call.

The spreadsheet exists because two businesses name the same object differently, and neither is wrong. This post is about what a purchase order needs to carry so that both names travel with it, why Shopify's native PO only half solves the problem, and how Restock Ops builds the mapping for you from the orders you already place.

Two codes for one product is normal

Your SKU is for you. It encodes whatever your shop finds useful: a category prefix, a season, a running number. It is what your barcode labels print, what POS scans, what your reports group by. The supplier's SKU is for the supplier: their warehouse pick code, their catalogue reference, the string their order desk types into their own system. Asking either side to adopt the other's code never works, because both codes are load-bearing somewhere.

A purchase order is the one document both sides read, so it has to speak both languages. The supplier needs their code to pick the right item; you need yours to receive against the right variant and put the cost on the right inventory item. When one code is missing, someone translates by hand, and hand translation is where the wrong colour ships or a case of six becomes six cases.

Where Shopify's own purchase order stops

Shopify's native purchase order does have a supplier SKU field on each line, and merchants report that once you have typed it for a variant and supplier, later POs to the same supplier fill it in. That is a real feature, and it is worth using if native POs are all you need. Its limits are the ones a June 2026 community thread lays out: the PO CSV import matches lines on your SKU or barcode, not the supplier's code, so you cannot seed or bulk-correct the mapping from a file, and there is no place to see all of a supplier's codes at once. The mapping exists, but only as a side effect inside individual POs.

That matters most at two moments. The first is onboarding a supplier with two hundred items, when the choice is between typing two hundred codes into the first PO or living without them. The second is when a supplier renumbers its catalogue, which happens more often than anyone admits, and every stored code is suddenly stale with no view to find them in. Our checklist of native PO gaps covers the rest of the list; this is the entry about identity.

A catalog that fills itself

Restock Ops keeps a catalog per supplier: for each variant you have bought from them, the supplier SKU, the last unit cost, the tax rate and the date you last ordered it. You do not maintain it directly. When you mark a purchase order as Ordered, the app reads every line and records those four fields against that supplier, creating the entry or updating it if the cost or code changed. The confirmation says so in plain words: Marked as ordered. Supplier catalog updated.

The next time you add that variant to a draft PO for the same supplier, the line arrives prefilled: their code in the Supplier SKU column, the last cost you paid, the tax rate you used. Your own SKU and barcode are on the line too, pulled from Shopify. So the third PO to a supplier is mostly a matter of choosing quantities, and the spreadsheet has quietly stopped being necessary.

While the PO is a draft, every line is editable inline, including the supplier SKU. If the supplier has renumbered, you fix the code on the line, and when you mark the PO as ordered the catalog learns the new value. Lines lock once the PO is ordered, so the record of what you asked for, under which codes, cannot drift afterwards.

What the supplier receives

The PO export is a CSV with one row per line. Each row carries the PO number, the supplier's name, your product and variant titles, your SKU, the barcode, the supplier SKU, quantities ordered and received, unit cost and tax. Send that file, or a spreadsheet made from it, and the supplier's order desk can sort by their column while you keep yours. There is no PDF designer and no email integration; the file is plain on purpose, so it opens anywhere and survives whatever the supplier does with it.

On your side, receiving works from your identifiers. A scanner reads the barcode on the box or the item, the receive screen jumps to the matching line, and the quantity goes to the right Shopify variant regardless of what the supplier printed on the delivery note. The two codes do their separate jobs and meet only on the document.

Mapping vendors to suppliers

There is a third name in the mix: Shopify's vendor field on the product. Vendor is the brand, and it is often but not always the supplier. A distributor may supply five brands; a brand may sell to you direct and through a wholesaler. Restock Ops lets a supplier record list the vendor names it supplies, so the product picker in the PO builder and the reorder report can suggest the right supplier for a product without you looking it up.

It is a suggestion, not a rule. Where two suppliers carry the same brand, both appear, and the catalog entries stay separate for each, because the same variant can have a different supplier SKU and a different price with each of them. That is also how you compare them: the supplier page lists the catalog with cost and last-ordered date, side by side.

Getting the first catalog in place

1. Create the supplier in Restock Ops with lead time, minimum order value, payment terms and the vendor names it covers. Put anything structured you cannot fit in a field, such as case sizes or discount tiers, in the notes; they show while you build a PO.
2. Build the first draft PO from your open spreadsheet. Add the variants, then type the supplier SKU, cost and tax on each line where the prefilled value is empty or wrong. This is the one-time cost, and it is the last time you type most of these codes.
3. Mark the PO as ordered. The supplier catalog is written from the lines at that moment; open the supplier page and check the Catalog section shows the codes you expect.
4. On the next PO, add products and watch the lines prefill. Correct anything the supplier has changed; the correction is learned when you mark it ordered.
5. When a supplier renumbers, export their most recent PO to CSV, update the supplier SKU column, and use it as your reference while editing the next draft. The catalog catches up as orders go out; there is no separate mapping to maintain.

What this does not do

Restock Ops does not write the supplier SKU into Shopify. It is not a product field there, and inventing a metafield for it would put a second copy somewhere that another app might read and trust. The code lives with the supplier and the purchase order, which is where it is used. If you want it on your product pages for some reason, a metafield is the right tool and it is a separate decision.

It also does not import a supplier's price list. The catalog learns from orders you place, so a code you have never ordered has no entry. For most small retailers that is the right shape: the products you actually buy get mapped in the first month, and the rest of the supplier's range stays their problem until you order it.

FAQ