Run an inventory sync long enough and one day you will push numbers you never meant to push. A sort operation shifted the rows. A test value was left in a cell. Quantities were entered in cases while the sheet expected units. The causes vary, but the feeling at the moment of realisation is remarkably consistent: your heart rate goes up a notch.
The good news is that inventory sync accidents are almost always recoverable if you work through them in order. And the order matters. Stop the damage spreading, establish what the correct numbers are, push the correction while checking as you go, and finally close the gap that allowed it. This article walks those four stages as an actual procedure. It assumes the mistake has already happened, so if you are dealing with one right now, just read straight down.
The first five minutes: stop the damage
The five minutes right after you notice are not for fixing anything. They are for making sure nothing gets worse. Whether you can resist the urge to touch the numbers here largely decides how hard the rest of the recovery will be.
Pause the scheduled sync first
The very first action is to pause the scheduled sync. The reason is simple: as long as the wrong figure is still sitting in the sheet, every scheduled run will faithfully write it back into Shopify. You can correct things by hand in the admin all you like, and the next run will overwrite your correction with the same mistake.
That loop of fixing something and watching it revert is the most exhausting pattern in any recovery, and because you believe you have fixed it, it can take a while to work out what is happening. Pausing a schedule takes a few seconds, so do it before you even start assessing the situation. Note down the time you paused it, too — that timestamp makes the later verification much easier.
Work out how far it spread
Next, establish the blast radius. Is the whole catalogue affected, or only a handful of SKUs? If you run several locations, which sites did the bad numbers actually reach? And the dimension people most often forget is time: how many hours the wrong figure was live changes how much work you have ahead of you.
The critical question is whether orders came in during that window. If you published more stock than you physically had, you may now have oversold. If you published less, the only consequence is that sellable products showed as out of stock, and restoring the quantity is the whole fix. The first case needs a plan for the affected orders on top of the inventory correction, so it is worth separating the two straight away.
This assessment does not need to be complete. Writing down whatever you can establish in five minutes is enough. Chasing precision here has a real cost, because the wrong figures stay live the whole time you are chasing it. Sketch the outline now and sharpen it in the next stage — that is the right tempo.
- 01Which SKUs: the whole catalogue, one category, or a specific range of rows in the sheet
- 02Which locations: whose on-hand quantities were actually overwritten
- 03The time window: from when to when was the wrong figure live
- 04Orders: did any orders come in for those SKUs during that window
- 05Direction of the error: did you publish more stock than you had, or less
Do not type in a fix before you know the right number
As the blast radius comes into focus, so does the temptation to open the admin and key in a number that looks about right. The impulse is entirely understandable, but from a recovery standpoint it is a poor move. A figure entered from memory or instinct gives you no way to tell whether it is wrong.
What makes it worse is that a hand-typed value overwrites the very evidence you are about to need. Every manual edit removes another clue about what the pre-incident value was, which makes the truth harder to reconstruct later. What this stage calls for is not correction but recording. Capture what Shopify currently holds for the affected SKUs — a screenshot or an export is fine — and you will be glad of it when you start reconciling.
Establishing what the numbers should be
Once the damage has stopped spreading, the job becomes working out how many units there actually were. You have three sources to lean on: the edit history of the sheet, the evidence Shopify kept on its own side, and, ultimately, the physical shelf. Work through them in that order.
The sheet's edit history knows the pre-incident value
If your spreadsheet is the single source of truth for inventory, its own version history is the most reliable clue you have. Most spreadsheet tools keep a record of who changed which cell and when, which means the pre-incident state is still sitting there. Roll the history back to just before the bad sync ran and read off the values as they stood.
One word of caution: do not restore the whole sheet from history in one move. Alongside the edit that caused the incident, there may well be legitimate updates made afterwards — goods received, stocktake corrections — and a wholesale rollback erases those too. The safer approach is to treat the history as read-only, copying the correct values out into a working sheet. Using it as a reference rather than a restore point avoids a second, self-inflicted incident. How version history saves an inventory sheet covers the mechanics.
Shopify kept evidence too
When the sheet history alone is not enough, Shopify holds material of its own. An inventory item carries a history of quantity changes, showing when the number moved and through which route. Because it distinguishes a sync update from an order commitment or a manual edit, it is a good way to pinpoint exactly where the incident entered the system.
Look at the orders and fulfilment activity from that same window as well. If anything shipped while the wrong figures were live, those units really have left the shelf — which means writing the pre-incident value straight back would now leave you too high. What you need is not the value from before the incident, but that value adjusted for everything that genuinely happened since. It is an easy step to skip and an awkward one to discover later.
- Inventory history: shows when a quantity moved and by what route
- Orders in the window: check whether anything sold against the wrong figure
- Fulfilment activity: anything already shipped has left the shelf for real
- Sync logs: match timestamps to find which run wrote the bad values
When the two disagree, count the shelf
Sooner or later you will hit a SKU where the sheet history and the Shopify evidence simply do not agree. No amount of discussion at a desk will settle which one is right. Inventory is physical, so the only tiebreak available is walking over and counting what is actually there.
That does not mean a full stocktake. You only need to count the SKUs where the sources disagree, at the locations the incident touched. Narrowed that far, it is often half an hour of work, and it buys you a level of certainty nothing else will. Once counted, put the figure into the sheet first, so the sheet is authoritative again before you move on to pushing anything.
Note the time of the count alongside the number. If something ships while you are still counting, the figure you wrote down is already historical. Knowing when you counted, and what moved afterwards, lets you adjust to a currently correct number rather than guessing. The busier the moment, the more that one extra line of notes will earn its keep.
Pushing the correction safely
With the correct numbers settled, it is time to send them back to Shopify. Rushing the whole catalogue through here is how one incident becomes two. Narrow the scope, verify, then widen — three beats, in that order.
Start with a deliberately narrow scope
Make the first corrective sync deliberately small. Pick five to ten rows from the affected set, and choose ones that differ from each other: a SKU stocked at several locations, one sitting at zero, one that took orders while the wrong figure was live. Covering a spread of cases lets a handful of rows prove a great deal.
Before you run it, use the connection test to confirm the destination store and location are what you intend. Recovery work is rushed by nature, and mix-ups happen in places you would never normally get wrong. If you keep both a development and a production store, those few seconds of checking are what stands between you and a second incident on top of the first. Use your pre-flight checklist before a full sync before you widen the scope.
Verify the small batch before widening
Once the small batch has run, check each row by eye in the admin. Look at the on-hand field specifically. The available figure is affected by unfulfilled orders and may legitimately differ from your sheet — that is not a fault. If on hand matches what you specified, the correction landed properly.
If even one row disagrees with what you expected, do not widen the scope. Increasing the volume while a cause is still unexplained makes isolating it dramatically harder. Stopping at a few rows to understand why is almost always the faster route overall. Once every row matches, widen in stages and finish with the full set.
- 01Pick five to ten affected rows that cover different cases
- 02Run the connection test to confirm the destination store and location
- 03Sync only that small batch and check on-hand quantities in the admin by eye
- 04If every row matches, widen the scope; if any row differs, stop and find out why
- 05Once the full set has been corrected, re-enable the schedule last
Re-enable the schedule last of all
When the full correction is done, the final step is to turn the scheduled sync back on. It comes last for a clear reason: a schedule trusts the sheet unconditionally. Re-enable it while the source data is still not right and it will cheerfully overwrite everything you just repaired.
So before you re-enable, confirm once more that the sheet is authoritative. Are the physically counted figures in it? Has the edit that caused the incident been removed? Have the receipts that arrived during the recovery been entered? When all three are yes, switch the schedule back on, then check the logs and a few quantities once more after the next automatic run. At that point you can genuinely call the recovery finished.
Making sure it does not happen again
With the inventory restored, the recovery is over — but the operational work has one step left. Closing the gap that allowed the incident is part of handling it. That said, not over-investing here matters just as much.
Look for the design flaw, not the person
After an incident, attention naturally drifts toward who made the edit. It is a question with very little payoff. Once a sheet is shared across a team, someone slipping is not an anomaly to be eliminated but a condition to design around, and in most cases it simply happened to be that person on that day.
The more useful question is why that ordinary action was able to turn into an incident at all. If a sort shifted the rows, the sheet allowed a SKU and its quantity to end up on different rows. If units were misread, the column header did not state the unit. Recast the cause as a property of the design and the thing to fix becomes concrete, which is exactly what tells you what to do next.
That reframing has a second benefit. Once the cause is a property of the system, the person involved can describe what happened without flinching, and a team that can share the facts accurately learns far more from each incident. When you sit down to review one, try starting with what rather than who.
Add exactly one guardrail
In the days after an incident it is tempting to list every safeguard you can think of. But a set of new rules introduced all at once tends to be quietly abandoned within a few weeks. What survives in a real operation is whatever adds almost no effort. So add one guardrail, not a new process.
Choose it by asking which single change would definitely have stopped this particular incident. If rows shifted, fix the sort range or protect the columns that should not be edited by hand. If the wrong kind of value went in, constrain what the cell will accept. If the destination was wrong, make the connection test a fixed habit before syncing. Put one in, let it settle, and add the next one after the next thing you learn. To catch it the same day next time, build what monitoring and alerts for inventory sync describes.
- Protected ranges: keep formula and reference columns from being edited by accident
- Validation rules: stop negative values or text from landing in a quantity column
- Connection test: make confirming the destination a fixed step before every sync
- Scoped range: sync only the rows that matter, so scratch rows never get swept in
Write the sequence down for whoever is next
The last thing worth doing is writing down the sequence you just followed. It does not need to be elaborate. Where the schedule is paused, what to check when assessing the blast radius, where to look for the correct numbers, and in what order to push the correction. A single page is plenty.
The value of that page shows up when the next incident lands on someone other than you. With the sequence written, they do not have to construct a plan under pressure; they can follow it from the top. What actually magnifies the damage in an inventory sync incident is rarely the response itself — it is the hesitation before the response. Writing it down once removes that cost for good.
An inventory sync accident looks enormous in the moment it happens, but the work it demands is entirely defined. Stop it, investigate it, push the correction while checking as you go — and then fix one thing in the design so the same shape cannot recur. Once you have been through it, the next one will find you reaching for the steps instead of the panic.