We use custom reporting to calculate inventory levels and purchasing requirements, but part of the equation hinges on the currently incoming inventory quantities, which no longer seem to work. This new purchase order system is already horrible but now the incoming inventory mechanism doesn’t seem to “see” what is on a purchase order, so my reports keep telling me to procure what is already in process.
Does anybody else see this? Can we please get some traction on reverting the purchase order system to the way it used to be? This will potentially hurt our the management of our capital.
For anybody looking, I finally found that you have to go to the PO, create a transfer, then mark that transfer as in-transit (even though it’s not yet), in order for the incoming inventory to show up.
Just another couple of steps in this ridiculous process that didn’t exist before. SO FRUSTRATING
I’d create the linked transfer as soon as the PO is confirmed, then add the expected arrival date and a note that it hasn’t actually shipped yet. That will at least make the quantities show as incoming so your purchasing report doesn’t keep recommending duplicate orders. If you’re processing a lot of POs, it may also be worth looking at an inventory planning app that counts open POs as incoming without this extra transfer step, because Shopify’s new workflow is pretty clunky.
The reason that extra step exists is that incoming isn’t derived from the PO at all. It’s derived from inventory shipments, so until a transfer exists and is marked in transit there is literally nothing for Shopify to count.
That also explains why your custom reporting can’t see it. As of 2026-07 there is still no PurchaseOrder object in the Admin GraphQL API, only InventoryTransfer and InventoryShipment, so anything you build is reading the transfer layer whether you want to or not.
One thing worth knowing before you lean on the workaround: marking a transfer in transit early decouples it from the PO. If the supplier short ships, or you edit quantities on the PO afterwards, the transfer does not follow. Your report goes back to over counting, just silently this time instead of loudly.
What helps is stamping the PO number onto the transfer itself (transfers accept metafields now) so the report can join the two instead of matching on name.
Is your reporting pulling from ShopifyQL exports or straight from the Admin API?
That would be a significant concern, especially if you’re relying on incoming inventory to drive purchasing decisions.
If purchase orders are no longer contributing to the Incoming Inventory values used in reports, it can lead to duplicate procurement recommendations and unnecessary inventory purchases. That has a direct impact on inventory planning and working capital.
Before assuming it’s a platform issue, I’d recommend confirming whether the purchase orders are in the expected status and whether the reports are referencing the new purchase order data model correctly. If everything appears to be configured correctly and incoming quantities still aren’t reflected, it does sound like something Shopify should investigate.
I’d be interested to hear whether other merchants using the new purchase order system are seeing the same behavior, as that would help determine whether this is a broader product issue or something specific to certain reporting workflows.
Your workaround is right, and it’s currently the only native way to do it: Shopify’s “incoming” inventory only gets populated by transfers marked in-transit. The new purchase orders don’t feed that field. So any custom report reading the incoming quantity will never see what’s on an open PO, which is exactly why it keeps telling you to re-procure stock that’s already inbound.
Two options depending on how much manual work you can stomach:
Keep doing what you found: raise an in-transit transfer off each PO, and have your report subtract incoming from the reorder point. Correct, but it’s the extra step you’re rightly annoyed about.
Move the reorder logic out of native reporting into a tool that tracks on-order quantities from its own POs, so “suggested reorder” is already net of what’s inbound and you never double-order. That removes the transfer dance entirely.
Either way the root issue is the same: native reorder reporting only knows on-hand + transfers, not POs, so you either feed it or replace it.
Full disclosure: I’m the developer of EasyRestock. Its low-stock/reorder suggestions subtract quantities already on open POs, which is the specific double-ordering problem you’re describing. Mentioning it because it maps 1:1 to your case, not to push you off a setup that works. Your transfer workaround is perfectly valid if you’d rather not add an app.
Hello there @HectorGomez
You’re not alone. A handful of sellers have reported that stock received through the the new purchase order workflow is not consistently showing up in reports, which can throw off restock planing. In the meantime, as a workaround you may want to create your purchasing reports based on purchase order line items directly or use a reporting app that can show open PO data until this behavior is fixed. That also helps keep inventory planning more accurate while eliminating double-buying decisions.
Now I find that the transfers don’t update when a PO is updated? I’m getting so aggravated at this platform. I have to create a transfer and prematurely mark it in transit so the actual inventory system functions properly, but then it doesn’t automatically update the dumb transfer page when a PO has to change. This is honesly ridiculous and makes me want to leave Shopify entirely.
@HectorGomez your setup – custom reporting to calculate inventory and purchasing – is exactly where the landed cost timing problem shows up. If your freight invoices arrive after the goods, your custom report is using provisional costs for anything sold in that window, and the margin is off without you knowing it.
What I am working on: a focused tool that does per-charge landed cost allocation (freight by weight, duty by value), a late-invoice true-up as a new revision instead of re-entering the PO, and an explicit report of how much the sold-unit margins were overstated while the cost was provisional. Plus inbound netting with overdue/unknown-ETA split.
Since you are already running a custom setup – would you be open to a 20-minute workflow review? I am pre-launch and trying to validate the late-invoice case against how people actually handle it. No sales pitch.
Hello, @HectorGomez
Hope you are doing great!
We’re seeing a similar issue. If incoming quantities from open POs aren’t being reflected correctly, purchasing reports can easily recommend orders for inventory that’s already on the way. That creates a real cash flow and overstock risk.