Tracing Shopify Inventory Changes

The number that doesn't match

You count the shelf and find seven. Shopify says three.

Or the reverse, which is worse: Shopify says eleven, you have none, and a customer has already paid for one. Now you are writing the apology email and deciding whether to refund, substitute, or wait on a restock that may be two weeks out.

Either way, the first question is the same one that follows every surprise in a store: what changed, when, and what changed it? And inventory is the field where that question is hardest to answer, because inventory is the field with the most hands on it.

Why stock drifts from more directions than anything else

Most data in a Shopify store is edited by one person, in one place, on purpose. A product description gets rewritten. A page gets a new paragraph. Inventory is not like that. It moves constantly, from several sources, most of which are working correctly.

Orders move it without anyone touching the admin. Every sale decrements a quantity. Every cancellation or refund may restock it, depending on how it was processed. None of this involves a human opening the product page, so none of it looks like an edit — but the number is different afterwards.

Apps move it on a schedule. A 3PL connector, a supplier feed, a POS, a dropshipping integration, a bundling app. Each one writes stock levels through the API, often nightly, often for hundreds of variants at once. When one of them is misconfigured, it doesn't make one mistake. It makes four hundred.

People move it in bulk. A received shipment gets keyed in. A stock take gets uploaded as a CSV. The bulk editor updates a filtered view that turns out to include more than it was meant to. These are the changes most likely to be large and least likely to be remembered a week later.

Locations multiply all of it. Once stock is split across a warehouse, a retail counter and a fulfilment partner, the same product has several numbers, and a change to one of them can look like a change to the product overall.

The Shopify admin is built to show you current state, and it does that well. Open a variant and you see the quantity right now, at each location, which is what you need almost all of the time. What it doesn't give you is the sequence — the eleven that became four on Tuesday afternoon, and whether that was the warehouse sync, a cancelled order restocking, or someone's spreadsheet.

What a useful inventory record contains

"Inventory changed" is not a finding. To actually close an investigation, a record has to carry four things.

The before and the after. Not a flag that something moved, but the two numbers. Eleven to four is a sale and a half, or a correction, or a sync. Eleven to zero is a different story entirely, and the difference between them is where your attention should go.

An honest actor. Whether the change came from a staff member, an app, or a system process — and, crucially, labelled as what it actually was rather than guessed at. An order-driven decrement is a system change. It should say so, not borrow the name of whoever happened to be logged in. Attribution is only useful if you can trust it when it says "app" instead of naming a person.

A timestamp you can line up against other events. Most inventory investigations are really correlation exercises. The count went wrong somewhere between the last trustworthy number and now, and the fastest way to narrow that window is to put the stock changes next to the order that oversold, the shipment that arrived, or the night the connector ran.

Enough history to cover the question. Inventory problems surface late. Nobody notices a quiet drift until a count, a reconciliation, or an oversell forces the issue, which can be weeks after the cause. How far back you can look is set by your data retention window, and it's worth knowing what yours is before you need it rather than during.

Adminlog records changes across 10+ entity types — including products, orders, inventory, collections, refunds and locations — with field-level before and after values and actor attribution that distinguishes staff, apps and system processes rather than inventing one.

Three moments this earns its keep

After an oversell. You already know the outcome. What you need is the cause, because the same misconfiguration will do it again next week. Reading the sequence of changes to that variant usually makes the culprit obvious: a sync that wrote a stale number, a restock that never happened, a manual correction that was undone by the next automated run.

When you're auditing an app. Installing something that writes inventory is an act of trust. A change record turns that trust into something you can check — you can see exactly what the app wrote, how often, and whether it stayed inside the variants it was supposed to touch. That is a far better basis for keeping or removing it than a hunch.

Before and during peak season. Going into a high-volume period, the risk isn't that inventory changes; it's that it changes in ways nobody notices until stock is being promised it doesn't have. Change velocity and anomaly detection matter here specifically: an unusual burst of inventory writes at 3am is worth seeing on the day, not in January.

Where the record stops and a count begins

This is worth being plain about, because it's the limit of what any audit log can do.

A change record tells you what your store believed its stock was, and when it changed its mind. It does not tell you what is physically on the shelf. If a box was damaged, miscounted at receiving, or walked out of the back door, no webhook fired and no log will show it. The record narrows the question from "the whole history of this product" to "these four changes in this window," which is usually the difference between an afternoon and five minutes — but the physical count is still yours to do.

There's a second limit worth knowing. Adminlog's one-click revert restores products to a previous state. Inventory is a live operational number, not a field you want silently rolled back underneath an open order, so the record's job here is different: it tells you the correct number to set, and from when. The decision to set it stays with you.

Both of those are features, not gaps. A log that claimed to know your warehouse would be guessing, and guessing is exactly what you're trying to replace.

A number is only as good as its history

Inventory accuracy isn't really a number. It's a chain of changes, and a store is accurate when that chain is unbroken enough to explain the number at the end of it.

If you can't currently answer "why does this variant say three?" without opening four tabs and asking two people, that's the gap worth closing — ideally before the peak period that will test it.

See how Adminlog tracks inventory and other store changes, with field-level diffs and honest actor attribution from the day you install it.