Guide 03 covered when to order and how much. This guide covers the part that happens next: running the supplier relationship, raising the order, and getting the stock onto your shelves without the process consuming a day a week.
It also corrects something you will read almost everywhere else, including in a great deal of content published since Stocky's retirement.
Does Shopify have purchase orders?
The standard line — repeated across comparison articles, vendor blogs and app listings — is that Shopify has no purchase order functionality and you must buy a tool. That is out of date.
Shopify admin has a purchase order module at Products → Purchase Orders. It will:
- Create and manage purchase orders, including importing line items by CSV
- Hold supplier records and assign a supplier to each order
- Set supplier currency and payment terms — cash on delivery, payment on receipt, Net 30 and so on
- Apply line costs and adjustments for shipping, fees or duties
- Receive stock against the order through a linked inventory transfer, with barcode scanning
- Handle partial deliveries as multiple shipments with accepted and rejected quantities
- Report on purchase order cost by supplier and SKU through custom explorations
- Run ABC analysis natively
Sidekick, Shopify's assistant, will also suggest what to reorder based on sales data and draft the purchase order for you.
For a store under £1m with a handful of suppliers, this is genuinely sufficient for the operational side, and it is free. Before you buy anything, use it for a quarter.
What will Shopify purchase orders not do?
The gaps are specific and worth knowing before you build a process around the module.
Lead times and minimum order quantities are metafields that drive nothing. You can create metafield definitions for supplier lead time, minimum order quantity, case pack and supplier SKU. Shopify's own documentation is explicit that these store information for your reference and are independent of purchase order ordering and receiving calculations. Case packs must be converted to units by hand.
This is the single most important sentence in this guide. You can write the lead time down. Nothing reads it. The number sits in a field, correct and inert, while the decision it exists to inform is made in someone's head.
Payment terms do not persist on the supplier. Currency and terms are saved on each purchase order, not as defaults on the supplier profile. You re-enter them every time, and you get them wrong occasionally.
You cannot email a purchase order from admin. Download the PDF and send it yourself.
Minimum and maximum thresholds require custom metafields, and nothing triggers on them automatically. Sidekick can draft an order that respects limits you have set, when asked. It is an assistant you consult, not a system that watches.
Purchase order APIs are not generally available. The Transfers API exists; purchase order APIs are in developer preview with read access only. If you intended to automate around POs, that route is not open yet.
Costing is single-value. Cost per item is one static field. No weighted-average costing, no landed cost allocation for duty or freight, so your margin figures diverge from reality the moment freight costs move.
No native spend-by-supplier report. You can export and build it. There isn't one waiting.
What supplier record do you actually need?
Shopify will hold a supplier. It will not hold what you need to know about them. Keep this in a spreadsheet alongside — six fields, updated after every order.
Measured lead time, not quoted. The elapsed time from you sending the PO to stock being sellable on the site. Record the last six. Use the longest, not the average — the average leaves you short half the time by construction.
Lead time variance. The spread between fastest and slowest. A supplier who ranges from four to nine weeks costs you five weeks of buffer stock on every line they supply, and that buffer is working capital. It is a legitimate thing to raise with them, and it is a stronger conversation with six data points behind it.
Minimum order quantity, per SKU where it varies.
Case pack. Because you will order 84 units and receive 96, and the reorder point you calculated is now wrong in a way nobody notices.
Price breaks. The quantity at which unit cost drops, and by how much.
Order cycle. How often you realistically place an order with them.
That last one is the field most often missing and it changes everything downstream.
Fixed cycle or reorder point
Two ways to run ordering. Most stores run a confused mixture and get the drawbacks of both.
Reorder point triggered. You order when stock hits the threshold from Guide 03. Optimal per SKU, and it produces frequent small orders — which is fine for a domestic supplier with no minimum and expensive for a container from overseas.
Fixed cycle. You order from each supplier on a set rhythm — every four weeks, say — and order enough of everything to cover until the next cycle plus lead time plus buffer. Slightly more stock overall, far less administration, and it consolidates freight and hits minimums naturally.
The rule of thumb: fixed cycle for suppliers with minimums, long lead times or meaningful freight cost. Reorder point for local suppliers you can call on Tuesday for Thursday.
If you run fixed cycle, the cover you need per SKU is larger than the Guide 03 figure, because you must survive until the next order arrives, not just this one:
Order-up-to level = weekly velocity × (order cycle + lead time + buffer)
The calculator accompanying Guide 03 uses exactly this for its suggested order quantity.
Receiving is part of the lead time
The component everyone omits, and frequently the largest one you actually control.
Stock arrives. It sits in the delivery area for three days because nobody has time to count it. It is not sellable, it is not in Shopify, and your reorder calculation assumed it arrived the day the courier did.
If your measured lead time runs from PO to courier, it is understating by however long your receiving backlog is. Measure to the point the stock is live on the site.
Shopify's receiving workflow helps here. Barcode scanning against a linked transfer, split shipments for partial deliveries, accepted and rejected quantities per receipt. Using it properly costs nothing and shortens real lead time more than any supplier negotiation is likely to.
Record rejections rather than absorbing them. A supplier who short-ships two per cent has effectively raised your unit cost by two per cent, and you will never notice unless it is written down.
What to build this month
- Use the native module for a quarter before buying anything. It is free and it covers the operational half.
- Create the supplier metafields anyway. Nothing reads them, but a lead time written down is a lead time a person can act on, and it is the substrate for anything you automate later.
- Keep the six-field supplier sheet beside it. Update it after every delivery, not from memory at quarter end.
- Choose a cadence per supplier — fixed cycle or reorder point — and write it down.
- Measure receiving separately from supplier lead time for one month. The number will be larger than you expect.
- Add a Flow workflow alerting you when an A-tier variant crosses its threshold. Flow will not raise the order. It will tell a person that the moment has arrived, which is the part that currently depends on someone remembering. The Flow recipes companion to this series has the configuration.
The App Ceiling
This section appears in every one of The Operational Guides. It describes where the advice above stops working.
Everything above holds to roughly £1m–£1.5m in annual revenue. Past that point the constraint changes, and it changes in a way that adding further apps does not address.
Apps are built to be sold to many stores. That is what makes them affordable, and it is also what limits them: an app can only act on the data inside its own boundary. Your forecasting tool does not know what your ad platform is spending. Your ad platform does not know what is out of stock. Your back-in-stock tool does not know what your supplier lead times are. Each app is correct within its own scope and blind outside it.
Below roughly £1m, a person bridges those gaps. Someone looks at the stock report, notices a line is running low, and adjusts. The bridging is invisible because it is absorbed into the founder's day.
Above roughly £1m, three things happen at once. SKU count rises, so there is more to bridge. Order volume rises, so the consequence of missing something rises with it. And the founder's time is now spent on growth rather than operations, so the bridging stops happening reliably. Nothing breaks visibly. Revenue keeps climbing. What changes is that a percentage of it begins to leak in places nobody is looking — advertising spend running against unavailable variants, stock accumulating in the wrong location, returns sitting unprocessed for a week and a half while the item they contain is out of stock and being advertised.
That is not an app problem, and no app solves it, because the solution has to sit between systems rather than inside one. It requires something built for your specific stack, your specific SKU structure, and your specific supplier terms.
Purchasing shows the ceiling more literally than anything else in this series. Shopify gives you a field for lead time and a field for minimum order quantity, and it tells you plainly that nothing computes against them. Every input a reorder engine would need is present in your store, correctly recorded, and unconnected. The gap is not missing data. It is missing wiring.
Where to start
Open your last six purchase orders for your largest supplier. Work out the real elapsed time from sending each one to the stock being live on your site.
Compare the longest with what the supplier told you their lead time was. The difference is the buffer you have been carrying without knowing it, and it is the most useful number you will produce this month.