The inventory question usually reaches me in a disguised form. Somebody oversold during a sale, or the warehouse count did not match the dashboard, and the conclusion has already been drawn: we need a system.
Sometimes that is right. Often the real problem is that nobody owns the number, and a system will simply record the wrong number more reliably.
So before anything else, let me separate two things that get used interchangeably and are not the same.
An inventory management system answers what do we have, and where is it.
An order management system answers what did we promise, and what stage is it at.
They overlap, and plenty of products do both. But the distinction matters when you are diagnosing, because overselling and stock drift are inventory problems, while split shipments, exceptions and order state confusion are order problems. If your pain is the second kind, I wrote about when a Shopify brand actually needs an OMS separately, and buying an inventory tool will not fix it.
This piece is about the first kind.
All platform details below are from official documentation, read in October 2026, and linked so you can verify rather than take my word for it.
Start with what you already have
Most founders underestimate their own store, so it is worth being specific about what Shopify does natively before deciding it is insufficient.
Per Shopify's inventory documentation, you get:
- Inventory tracking, with control over what happens when a product goes out of stock
- Multiple locations, with rules for how each one fulfils orders
- Transfers to move stock between locations
- Adjustment logging, so you can see when and why a quantity changed
- Stock counts, for checking records against what is physically on the shelf
- Purchase orders linked to inventory transfers, for restocking from suppliers
That is a genuinely capable baseline. Purchase orders and stock counts in particular are features a lot of brands go and buy separately without checking whether they already have them.
On capacity: Shopify's India pricing includes 10 inventory locations on Basic, Grow and Advanced, and 200 on Plus. In practice, running out of locations is almost never the reason anybody upgrades.
And what a spreadsheet still does fine
I will defend the spreadsheet longer than most people in my position.
If you have one sales channel, one place where stock physically sits, and a catalogue you could count in an afternoon, a well-kept sheet plus your store's native tracking is not a compromise. It is the correct tool. It is free, everyone can read it, and it does not need an integration.
The sheet stops being right at a specific moment, and it is worth naming precisely: when the same number lives in two places and a human keeps them aligned by hand.
That is the real line. Not revenue, not SKU count. The moment accuracy depends on a person remembering to update twice, you have built a system whose reliability is a function of someone's attention on a bad week.
The five triggers that actually mean something
Here is what I would look for, in rough order of how commonly they arrive.
1. A second sales channel that sells the same unit
This is the big one, and it is usually the first.
One physical item, listed on your own store and a marketplace. Both can sell it. Neither knows about the other until a sync runs.
The gap between those two moments is where overselling lives. It is not a theoretical risk, and it gets sharply worse during a sale, because that is exactly when both channels are moving fastest and your sync interval has not changed.
A hypothetical example, to be concrete: you hold eleven units of one SKU. Your own store sells four during a flash sale while a marketplace sells nine in the same hour. Both were working from a stock figure that was true when they last checked. You now owe thirteen units and have eleven, and you find out when the warehouse tries to pick them.
If you sell one unit across two channels, you need something that holds a single authoritative number. That is the clearest trigger there is.
2. Stock in more than one physical place
Two warehouses, or a warehouse plus a retail counter, or your own unit plus a 3PL.
Shopify handles multiple locations natively, so this alone is not automatically a trigger. It becomes one when you need logic rather than storage: which location should serve which order, what happens when the nearest one is short, whether you split the shipment or delay it.
Location support tells you where things are. It does not decide what to do about it.
3. Bundles and kits
This one is a genuine platform constraint and it catches people out.
Shopify's documentation states that to create product bundles on your store, you must have a bundles app installed. Bundles are not native.
There are channel limits too: bundles sell through the Online Store, Shop and Shopify POS, and on Google and YouTube only fixed product bundles are supported.
The underlying difficulty is that a bundle is not a product, it is a claim on several products. Selling one gift set has to decrement three component stocks, and if those components also sell individually, you now have an availability calculation rather than a number.
If bundles are a sideline, an app covers it. If bundles are how you actually sell, this is a structural requirement and you should plan for it rather than patch it.
4. Returns that go back into sellable stock
Every return is an inventory event with a decision attached. Is this unit sellable, damaged, or to be written off?
With low volume you handle it by looking at the item. At higher volume you need a defined path, because returned stock that never gets restocked is money sitting in a box, and returned stock that gets restocked when it should not be becomes somebody's bad second experience.
In the Indian market this trigger arrives earlier than most founders expect, because refused and returned deliveries add volume that nobody planned a process for.
5. You cannot reconstruct what happened
This is the quiet one, and it usually shows up during an argument rather than an outage.
A count is wrong. You want to know when it went wrong and who changed it. Shopify logs adjustments, and its developer community indicates you can view the last 180 days of adjustment history for a product or variant, up from the 90 days quoted in older posts.
For most brands that window is plenty. If you need a trail that outlives it, or you need to answer the question across thousands of SKUs rather than one at a time, you need something that keeps its own history.
A short decision checklist
Answer these honestly. They are better predictors than revenue.
- Does one physical unit appear on more than one sales channel?
- Does stock sit in more than one place?
- Do you sell bundles or kits made of individually sold components?
- Does anyone currently update the same stock number in two systems by hand?
- In the last quarter, did you oversell and have to cancel or apologise?
- Can you say, today, who owns stock accuracy by name?
- Could you reconstruct why a count changed six months ago, if you had to?
Two or more yes answers on questions one to five, or a no on question six, and I would start looking seriously.
A no on question six is worth treating as a blocker rather than a trigger, though. If nobody owns the number, buying a system transfers that ownership to a tool, and the tool will record whatever it is given with perfect fidelity.
A phased way to move
I would not do this as a single project. Three phases, each of which is useful on its own.
Phase one: make the current number true. Before anything else, do a full physical count and reconcile it against what the store says. Fix the discrepancies and write down where they came from. This is unglamorous and it is the only phase that is genuinely mandatory, because every later phase inherits whatever you do here. You will also learn more about your actual failure modes in this week than a vendor demo will tell you in a month.
Phase two: establish one authoritative source. Decide which system holds the real number, and make every other system read from it rather than hold its own opinion. This is a decision before it is a purchase. Many brands find that their store is the right source and the problem was simply that nobody had said so out loud.
Phase three: add the layer you actually need. Now buy, with a specific requirement rather than a category. Multi-channel sync is a different product from bundle management, which is different again from warehouse operations. Having done phases one and two, you will know which sentence describes your problem, and you will not pay for the other two.
What I would tell a founder asking today
If you have one channel and one location, you do not need an inventory system. You need a weekly count and a named owner.
If you have two channels selling the same unit, you need one authoritative number, and that is worth paying for.
If you have bundles at the centre of your model, plan for that structurally rather than hoping an app absorbs it.
And if the honest answer to "who owns stock accuracy" is a shrug, fix that first. It costs nothing, it takes an afternoon, and it will change what you need to buy afterwards more than any feature comparison will.
