Shopify purchase orders now create transfers: what changed

When we wrote about what to replace Stocky with, Shopify's native purchase orders had one glaring weakness: you could not receive them in parts. That is no longer true. On June 26, 2026 Shopify shipped a change that connects purchase orders to inventory transfers, and receiving now happens through the transfer, with multiple shipments, partial deliveries and cost adjustments. This is the honest update: what native purchase orders now do well, what they still do not do, and where a purchase-order app still earns its monthly fee.

What the June 2026 change actually does

Shopify's help centre describes the split like this: the purchase order records the commercial agreement with the supplier, and a linked inventory transfer handles the physical movement of goods. The comparison Shopify itself draws is an order and its fulfilments. One record captures what was agreed, the other tracks what moved.

In practice you create the purchase order, mark it Ordered once the supplier confirms, and then create a transfer from it. The transfer comes pre-populated with the supplier as origin, your location as destination, and the same line items and quantities. From there it behaves like any other Shopify transfer: you process it, Shopify creates a shipment, and you receive shipments as they arrive, accepting or rejecting quantities per line. Receiving works in the admin and in Shopify POS, and POS receiving supports a barcode scanner.

Two smaller pieces came with it. You can import purchase orders from a CSV, which matters if a supplier sends you their order confirmation as a spreadsheet. And unit costs on the purchase order can be pre-filled from the cost already recorded on the variant, so you are no longer typing every cost by hand. Each purchase order supports one linked transfer at a time, and the two records show up on each other's pages.

What this fixes

• Partial receiving. A supplier sends 60 of 100 units; you receive 60 on the first shipment and the remaining 40 on a second one. Because receiving is per shipment, the purchase order no longer has to be closed or duplicated to reflect what actually arrived.
• Incoming quantity on the product page. Transfers count toward Shopify's incoming inventory state, so once the linked transfer is processed the ordered units appear as incoming on the variant. The old standalone purchase order never did this.
• Receiving at the shop counter. Staff can receive a shipment on POS with a scanner instead of walking to the back office, which is where receiving actually happens in most small retailers.
• Cost adjustments at receipt. If the landed cost differs from what was ordered, the transfer lets you adjust it when you receive, and the variant's unit cost updates.

What it still does not do

This is the part that decides whether you need anything on top. We keep a running list of the gaps Restock Ops exists to fill, and re-checked each one against the June change and the current Admin API documentation.

• Supplier records are thin. A supplier in Shopify is a name and contact details you can set as a transfer origin. There is no place for lead time, minimum order quantity, price breaks, payment terms or the notes you keep about who to call when a delivery is late.
• Cost history does not exist. Shopify holds one unit cost per variant. When a receipt updates it, the previous value is gone, so you cannot see that a product's cost has crept up 18% over four orders.
• No invoice tracking. A purchase order has no paid or unpaid state, no due date and no invoice number. If your accountant asks which supplier invoices are outstanding, the answer is not in Shopify.
• No labels from the receipt. Receiving 40 units does not give you 40 barcode labels. You still go to a separate label tool and re-select the products.
• No reorder suggestions from your own sales. Nothing in the purchase-order flow looks at last month's sales velocity and tells you what is about to run out.
• Apps cannot write purchase orders yet. Shopify's Admin API exposes purchase orders as read-only objects in the 2026-10 release candidate, with no create, update or receive mutations documented. So no app, ours included, can push a purchase order into the native record today. That will change; it has not yet.

How Restock Ops fits alongside native purchase orders now

There are two sensible ways to run this, and which one you pick depends on how much of your ordering is routine.

The first is to let Shopify's purchase order and transfer own the movement, and use Restock Ops for what sits around it: supplier notes and lead times, invoice status and due dates, cost history per variant, labels for what just arrived, and the reorder report that tells you what to order next week. The stock numbers stay in Shopify, where they were anyway.

The second is to run the purchase order in Restock Ops end to end. You create it by hand or from the reorder report, receive it in parts, and before anything is written the app shows you the exact quantity and unit-cost change per variant. Confirm, and it writes to Shopify's available quantity and cost through the inventory API, with every write logged and reversible. In this mode the native purchase order is simply not used. Because the API is read-only for purchase orders, Restock Ops cannot currently link its document to a native one, and we would rather say so than pretend otherwise.

Either way, Shopify remains the source of truth for quantities. Restock Ops never keeps its own stock count that could drift from what POS and the online store sell against.

A practical way to decide

If you place a handful of orders a month from suppliers who ship complete, native purchase orders with a linked transfer are now good enough, and you should use them. If you order from several suppliers, receive in parts, chase invoices, print labels at receipt or want to know what to reorder before you run out, the native flow still hands you a spreadsheet's worth of side work. That side work is what Restock Ops is for, and the June change did not remove it; it moved the line so that the remaining gaps are the operational ones rather than the basic ones.

Our earlier posts on partial receiving and barcode stocktakes describe those workflows in Restock Ops in detail, and the Stocky replacement guide covers the full migration if you are still on Stocky.