Architect's notesShopify transfers now mark stock that will never arrive
It is year-end, and the finance team has just written off thirty-eight thousand dollars across the brands. The warehouse says the stock was received short, the Shopify admin still shows the transfer as open, and Business Central has its own number for what should have come in. Nobody can point to the moment the numbers diverged, only the total. So the business books a write-off and hopes it is a one-off.
The pain is not just the money; it is that three systems, Business Central, the warehouse management system (WMS) and Shopify, each hold their own stock truth, and an adjustment made in one does not always arrive in the others with a reason attached. When an inbound transfer line never turns up, one system marks it short, another leaves it unreceived, and the third records it as something it was not. That gap is where year-end surprises start.
What changed
In September, Shopify added a canceled receive action to its inventory shipments API. The change ships in GraphQL Admin API version 2026-10, so existing apps on earlier versions are unaffected. In plain terms, when an item on an inbound inventory shipment will never arrive, an app can now mark it as canceled instead of leaving it open forever or pretending it was rejected. Shopify puts it accurately: “units either sat unreceived forever or had to be misrecorded as rejected.” Canceled-only receives also now trigger a webhook the same way accepted or rejected ones do, so a cancellation is a first-class event rather than a silent gap.
What caught my eye is the webhook change. Until now, a connector built against an older version could miss an entire cancellation and leave the downstream systems arguing about stock that was never going to arrive. Now that signal can flow through like any other receive event.
How we would wire it
Picture the multi-brand retailer above. The flow we would build looks like this:
The trigger is the receive event in Shopify. When a shipment line is accepted, rejected, or now canceled, Shopify sends an event that starts the flow.
We read the outcome in plain status terms. The event now carries a clear canceled status alongside accepted and rejected, so the integration knows what happened without guessing from missing quantity.
The same status lands in the ERP and warehouse system. Canceled units are posted to Business Central with a reason that closes the purchase order or transfer line, and the WMS is updated so its on-hand figure does not include stock that will never arrive.
A person handles exceptions in the shared chat. If the accepted, rejected and canceled units do not match the expected shipment quantity, or if a vendor cancels units that had already been allocated to orders, the flow stops and posts to Teams. One person checks one discrepancy, not a months-long trail.
Kori watches the daily three-way reconciliation. It compares Shopify, Business Central and the WMS for drift in received, canceled and adjusted lines, and alerts the team before the gap becomes a write-off.
One edge case worth naming: a canceled-only receive was previously silent on older API versions, so a connector built against one of those versions could miss an entire cancellation. We would pin the Shopify connection to the new API version and specifically test that the flow still runs when only the canceled quantity changes.
The ERP stays the ERP, the warehouse stays the warehouse, and the customer still owns the integrations and the Shopify app credentials. When Shopify changes the inventory-transfer model again, the receive step is the only part we swap.
Where this stops
We would not reach for this just because the announcement is new. If the business does not receive inventory through Shopify transfers, for example, if the 3PL owns the receiving process and Shopify only sees the final stock position, then canceled receiving in Shopify is irrelevant and the cleaner design is to update the ERP and warehouse directly from the 3PL. This is also not a substitute for a stocktake; it records what happened to a shipment, it does not verify what is on the shelf. And if integrations are already skipping receive events because the team has never agreed which system owns the stock truth, adding another field will only add another place for the numbers to disagree.
The next step
If your adjustments, short receipts or canceled inbound lines keep surfacing at year-end rather than when they happen, that is the conversation to have. We can map where your receiving events actually occur and which system should own the stock truth. An hour on your systems is where we would start.
The vendor update is real and linked. The business in this story is a composite of NZ operators we have worked with and talked to; names, figures and details are changed.
