Shopify inventory history: what it keeps and loses
Shopify keeps an adjustment trail, not a daily stock ledger. What history is actually available, and how to rebuild the rest from exports.
InventoryX is in development and not available today. ClearStock is the live Shopify app.
Shopify does keep an inventory history — but it is a history of changes, not a history of levels. Open any variant page and the adjustment history shows who changed what, when, and (if a reason was picked) why; the Inventory adjustment changes report lets you slice those entries across products, locations, staff, apps, and reasons. What the admin does not keep is a queryable record of what your on-hand quantity was on each past date, or how many days a SKU sat at zero. That second gap is the one that matters when a supplier asks what you sold last quarter, when your accountant asks what you held at year-end, or when you need to know why a bestseller's velocity looks wrong.
This is the map: what is stored, where it lives, how long it lasts, and the three reconstruction methods that get you the daily picture Shopify never wrote down.
What Shopify actually records
At the time of writing (November 2026), the inventory trail has five surfaces:
| Surface | What it holds | Where | Retention |
|---|---|---|---|
| Variant adjustment history | Every change to a variant's quantities: manual edits, orders reserving stock, receipts, transfers, app holds, with who and why | Product → variant → View adjustment history | Last 180 days per product, as documented |
| Inventory adjustment changes report | The same events across the catalog, filterable by SKU, location, staff member, app, and reason | Analytics reports | Depends on plan; this is the long-memory surface |
| Purchase orders and transfers | Order date, expected arrival, receive date, quantities per line | Products → Purchase Orders; Inventory → Transfers | As long as the record exists |
| Order history | Every order with line items, dates, and the inventory the order consumed | Orders | Effectively permanent |
| Inventory CSV export | A snapshot of on-hand, committed, unavailable, incoming, and available per variant per location — at the moment you export | Products → Inventory → Export | Only as long as you keep the files |
Read that table as two columns of very different reliability: the event records (adjustments, POs, orders) are durable, attributed, and rich. The quantity record is a snapshot with no past tense — export it and you own a photograph; don't, and the day is gone for good.
The three things it forgets
1. Daily on-hand quantities. There is no date picker that says "what did I have on March 14." The only evidence is the adjustment sequence: reconstruct the balance forward from any known point by replaying the deltas. Possible, tedious, and only as accurate as the trail is complete.
2. Out-of-stock days. A variant that sat at zero records zero sales for that period, which reads identically to zero demand. No native report counts dark days per SKU, which is why the lost-sales conversation usually starts with a reconstruction and not a report (the full method for recovering dark days).
3. What your numbers were before 180 days ago, at product level. Older movement is summarizable in the reports if your plan includes them, but the per-product narrative — the actual sequence of "received 24, sold 6, adjusted −3" — ages out of the variant screen. Stores that rely on the trail for accounting export it periodically rather than assume it waits for them.
Reconstruction method 1: replay the adjustment trail
Best for one SKU and a specific question ("why is this number wrong?"). Start from today's quantity and walk backward through the history, or start from a known-good point — a count — and walk forward. A rebuild for a single variant, illustrative:
| Date | Event | Delta | Running on hand |
|---|---|---|---|
| Sep 2 | Stock count applied (reason: Count) | set to 84 | 84 |
| Sep 9 | Order #1041 reserved 2 | −2 | 82 |
| Sep 15 | Receipt, PO 2026-118, 48 units | +48 | 130 |
| Sep 22 | Damaged, 3 units written off | −3 | 127 |
| Oct 1 | Bulk edit (no movement trail) | −40 | 87 |
| Oct 6 | Order #1128 reserved 2 | −2 | 85 |
The bulk edit on October 1 is the nutrition label of this method: bulk edits change quantities without recording a movement trail, so the row exists as a number change with no provenance. If your rebuild hits one of those, the trail stops being a history and becomes a guess. The mechanics of each activity type — Set to versus Adjust by, and what the reason field records — are covered in the inventory adjustments guide.
Reconstruction method 2: order history as a demand ledger
Best for the question "what did I sell, and when?" Orders are complete where snapshots are sparse: date, variant, quantity, location. Two things you can build from them without any other source:
- True sell-through by period. Units sold per SKU per week, with returns and cancellations excluded, is the honest denominator for any velocity calculation — and it is recoverable for years back.
- Probable dark windows. For a near-daily seller, a run of zero-sale days between two sales marks a period it was probably out of stock. That inference is reliable for fast movers and unreliable for the tail, where a quiet week is just a quiet week.
What orders cannot tell you is what was on the shelf — an order proves a unit left, not what remained. That is why order-based reconstruction gives you demand and dark windows but not inventory value.
Reconstruction method 3: the snapshot archive (the one that pays forward)
The only method that produces real daily history is the boring one: capture the export on a schedule.
- Export on a fixed cadence. Weekly is the minimum for planning-grade answers; daily if stockouts are expensive for you. Name the file with the date and keep it in one folder — the inventory CSV guide covers the two formats and which columns are read-only.
- Append, don't overwrite. One row per variant per location per date: date, SKU, variant, location, on hand, committed, unavailable, incoming, available. A weekly append at 500 SKUs is a few thousand rows a quarter — trivial in a spreadsheet.
- Derive the missing reports. Days at zero is a count of snapshots where available = 0. Restock dates are the transitions from 0 to positive. Net change per week is a subtraction between consecutive rows, which is the closest thing to a movement report you can build without the API.
The limit to state plainly: an archive started today has no history for yesterday. Every store that wishes it had daily quantities from last year is one export away from having them next year.
What to reconstruct first, in order
Reconstruction is expensive, so spend it where it changes a decision:
- Your top 20 SKUs, last 90 days. Enough to see which went dark, for how long, and what the velocity correction should be. This is the set where a wrong number costs the most.
- The current fiscal year's ending quantity. For the valuation, walk backward from today's on-hand using receipts and sales rather than trusting a remembered figure.
- Any SKU with a supplier dispute open. The adjustment trail plus the PO receive date is usually enough to prove a short shipment, and it's the cheapest evidence you will ever assemble.
Where the numbers come from afterwards
If you work in a spreadsheet, the reconstruction above is your history system: a snapshot column set plus the computed columns that turn consecutive snapshots into velocity and cover. If you would rather not maintain it, note the honest state of tooling: the inventory reports overview marks exactly which native reports exist and which questions they leave open, and the planning tools that fill the gap are still early. Our own InventoryX is in development as the buying and planning layer — a per-SKU record of dark days and in-stock demand — and it is not a live app today, so it is not a reason to skip the export habit. ClearStock, our live app, works on discounting slow stock and does not store inventory history.
Two boundaries worth keeping straight: the audit trail that explains a single change is a different artifact from the ledger that explains a quarter, and the discipline that keeps both honest is counting — counts and their cadence are what make a reconstructed number true rather than merely plausible.
Common questions
Does Shopify keep inventory history? Yes, as a record of changes: every variant has an adjustment history showing manual edits, order reservations, receipts, transfers, and app holds, with who made the change and the reason chosen. The admin view covers the last 180 days per product at the time of writing, and the Inventory adjustment changes report provides a catalog-wide, filterable view.
Can I see my inventory level on a past date in Shopify? Not natively. Shopify stores current quantities plus the changes that produced them, not a daily balance per SKU. You can reconstruct a past level by replaying the adjustment trail from a known point, or you can keep a dated export archive and read the level directly.
How long does Shopify keep inventory adjustment history? The variant-level history shown in the admin covers the last 180 days per product as of November 2026. Anything older depends on the reports available on your plan, which is why stores that rely on the trail for accounting or supplier claims export it on a schedule before it ages out.
How do I export inventory history from Shopify? The inventory CSV export is a snapshot, not a history — each export captures quantities at that moment. To build history, export on a fixed cadence, keep each file date-stamped, and append rows to a master sheet.
Why does my inventory history show changes I didn't make? Most unexplained entries are automatic: orders reserving stock, transfers being created or received, app holds, or system corrections. The activity column names the process and the created-by column names the app or staff member, which is usually enough to identify the source without guessing.
Next step
Open one fast-moving variant and read its adjustment history end to end — five minutes, and it tells you whether your trail is a history or a list of anonymous number changes. Then set the recurring export: one folder, one filename convention, one reminder. That single habit is the difference between reconstructing next year's history and having it.