Shopify inventory reports now use on hand: what a stocktake should set

On September 1, 2026 Shopify changed what its inventory reports count. Until then the analytics models behind inventory reports and ShopifyQL's inventory tables measured available quantity, the units you could still sell. From that date they measure on-hand quantity, every unit physically at the location, including units already sold but not yet shipped and units marked unavailable. Shopify's changelog says reported inventory “may be higher than before by the number of committed and unavailable units”, and that nothing before September 1 is restated.

If a report that used to agree with your stockroom suddenly shows more stock than it did in August, that is why. Nothing moved. The definition did. This post explains the states behind that change, how they relate to the number a scanner gives you when you count a shelf, and why the quantity you set after a count and the quantity you report on are not, and should not be, the same field.

The four numbers Shopify keeps per variant per location

Shopify's help centre defines the states plainly, and the arithmetic is the part worth memorising: on hand equals committed plus unavailable plus available. Incoming is tracked separately and is not part of on hand, because it is not in the building.

Why the reports moved to on hand

Available is the storefront's number. It is what decides whether the Buy button works, and it drops the moment an order is placed, long before the box leaves. That makes it a poor measure of what a store is holding. A shop with 40 units of a jacket and 15 open orders for it shows 25 available, and a sell-through or days-of-inventory calculation built on 25 is describing a stockroom that does not exist; there are 40 jackets on the rail.

On hand is the physical number, which is what stock valuation, shrinkage and cover calculations want. Shopify's change brings the reports in line with that. The side effect is that any dashboard, spreadsheet or reorder rule that read the inventory reports as “sellable stock” now reads a bigger number, and for products with a lot of open orders or a lot of held units the difference is material. Shopify notes that ShopifyQL queries reading FROM inventory or FROM inventory_by_location reflect the change, so saved reports and third-party exports built on those tables shifted on the same day.

Historical data is unchanged. A trend line that crosses September 1 therefore has a step in it that is definitional, not real. Annotate it, or compare like with like by looking at committed and unavailable on the dates either side.

What a physical count actually measures

When someone walks the shelf with a scanner, the number they produce is on hand. They cannot see which of the 40 jackets belong to open orders; the jackets look identical. So the only honest comparison for a count is counted versus on hand, and a discrepancy is counted minus on hand.

The mistake this change makes more tempting, not less, is to type the counted number into available using Set to. If the shelf says 40 and available shows 25 because 15 are committed, setting available to 40 does not correct anything. It creates 15 jackets that do not exist, which will sell and then fail to ship. Shopify's help centre describes Set to as the tool for after a physical count, which is right, but it belongs on the on-hand field, where Shopify adjusts available by the same amount and leaves committed alone.

There is a second, quieter problem with Set to after a count: time. Counts take an afternoon, and the store is usually open. If three jackets sell between the moment the shelf was scanned and the moment the number is typed, a Set to the counted figure overwrites those sales. The post on reversing a wrong adjustment goes into why a delta beats a set for corrections; the same logic applies to the count itself.

How Restock Ops applies a count

Restock Ops stocktakes are built around that arithmetic rather than around a Set to. The sequence is deliberate:

1. When a variant is first scanned into a count, the app reads Shopify's on-hand quantity for that location at that moment and stores it as the line's expected value. Scanning adds to counted; expected stays put.
2. The review screen shows expected, counted and the difference per line. Lines with no difference are left alone entirely; nothing is written for them.
3. Before applying, the app re-reads on hand for every line with a discrepancy. If any has changed since the count started, the apply is refused with a list of what moved, and you refresh the expected values and review again. A count is never applied against stale numbers.
4. The discrepancies are written as one adjustment per line of counted minus expected, on the available quantity, with Shopify's own cycle_count_available reason, in a single idempotent mutation. Shopify is also given the available quantity the app just read as the expected starting point, so if a sale lands in the seconds between the re-read and the write, Shopify rejects the whole adjustment rather than applying a stale count.
5. Every write carries a reference to the stocktake, so it appears by name in Shopify's inventory history, and an undo issues the inverse deltas with the correction reason, linked to the original.

Why the delta goes on available when the count is of on hand

This looks like a contradiction and is the heart of the matter. The discrepancy is computed against on hand because that is what was counted. It is applied to available because that is the state Shopify lets an app adjust by a delta, and because a delta on available moves on hand by exactly the same amount while leaving committed untouched. Count 38, expected 40: minus two on available, on hand becomes 38, the 15 committed jackets are still committed. The three sales that happened mid-count each reduced available and on hand by one on their own; the delta does not know or care about them, which is the point.

A Set to on hand of 38 would have arrived at the same place only if nothing sold during the count. A Set to available of 38 would have been wrong by the committed quantity. The delta is the only one of the three that is right in all cases, which is why Shopify ships a reason code specifically for it.

Reading your reports after September 1

• Stock value and days of cover: now based on on hand, which is what you wanted all along. If you had a correction factor for committed units, remove it.
• Reorder triggers built on reports: an on-hand reading overstates what you can sell by the committed quantity. Restock Ops' reorder report reads on hand and incoming directly and treats committed units as already gone when it computes a suggested quantity, so it is unaffected; a spreadsheet that pulled “inventory” from a report before September is now too optimistic by the open-order quantity.
• Shrinkage: compare count results, not report snapshots, across the change. A stocktake's expected-versus-counted is the same measurement on both sides of the date.
• Finance: tell whoever reconciles stock to accounting that the step on the chart is a definition change, and point them at the changelog entry below.

Short version

Reports now show what is on the shelf. Counts have always measured what is on the shelf. The number a count should change is the difference between the two, applied as a delta with a reason, after checking that nothing moved. Restock Ops does that for every count by construction, and the barcode stocktake guide walks through the scanning itself.

FAQ