One stock, three channels: how overselling actually happens
You had four units. You sold four units. Then a fifth order arrived, and you had to cancel it.
Nobody counted wrong. The shelf was right, the listing was right, and the order was still impossible — because between the moment a buyer pressed Place order and the moment your stock figure changed, something else sold the same unit.
Overselling is a timing problem, not an arithmetic one. Every fix that works is a fix to the timing.
The gap, in slow motion
Follow one unit through a normal day.
09:10 — a buyer orders it on the marketplace. Your stock figure has not moved. Nothing has been packed.
09:40 — a walk-in customer buys the same unit at the counter, because as far as the counter is concerned the shelf still holds it.
11:00 — you go to pack the marketplace order and there is nothing to pack.
At no point did anyone make a mistake. The unit was sold twice because for one hour and fifty minutes it was spoken for and still counted as available. That window is the whole problem, and every channel you add makes it wider, because there are more ways to enter it.
Why "just deduct at the order" is the wrong fix
The obvious answer is to take the stock off the moment the order arrives. It is obvious and it is wrong, for a reason that costs more than the overselling did.
Marketplace orders get cancelled. Buyers change their minds, the payment fails, the platform cancels for its own reasons, and a meaningful share of what is ordered never ships. If you deduct at the order, every one of those cancellations has to put the stock back — and if a single one of those put-backs is missed, that unit is invisible forever. It is on your shelf and not in your figure. You will not find it until someone does a physical count, and by then you have no idea when it went missing.
Deducting at the order trades a visible problem for a silent one. That is a bad trade.
Reserved is not sold, and not available either
The fix is a third state.
- On the shelf — what you physically have.
- Reserved — spoken for by an order that has not shipped.
- Free — on the shelf, minus reserved. This is the only number any channel should ever be shown.
Now walk the same day again. At 09:10 the marketplace order reserves the unit. The shelf still says one, because the unit is genuinely still there — but free stock says zero, so the counter will not sell it and no channel will offer it. At 11:00 you pack it, and only then does it actually leave the shelf.
If that order is cancelled at 09:30 instead, the reservation simply stops applying. Nothing has to be put back, because nothing was taken.
The stock leaves once, at the moment the goods physically leave. Everything before that is a hold, and a hold that is wrong costs you nothing to correct.
The mistake that makes reservations rot
Most systems that hold reservations hold them by adjusting a number: order arrives, add one; order cancels, subtract one; order ships, subtract one and take the stock.
This works until an event is missed. A sync fails, the platform sends a status late, a bug swallows one message — and the number is now wrong permanently, because nothing will ever revisit it. Phantom reservations build up quietly. Six months later a product with eleven units on the shelf shows three available, nobody can explain it, and somebody "fixes" it by typing a number in, which is how the next problem starts.
The alternative is to recompute the whole reservation from the current list of open orders, every time, and never adjust it event by event. It sounds wasteful and it is the only version that heals. A cancelled order, a double sync, an outright bug — all of it corrects itself on the next run, including the drift that already happened. You cannot accumulate an error in a figure you throw away and rebuild.
If you are evaluating a system, this is a fair question to ask: when a sync fails, does the number repair itself, or does someone have to notice?
Five places the gap actually opens
1. One item, two SKU codes
The same physical product listed on two channels under two different codes is, to every system involved, two products. Each has its own stock, each sells happily, and between them they sell twice what exists.
This is the most common cause and the least interesting, which is why it survives so long. The fix is dull: one product, one internal code, and every channel's listing mapped to it. Do it once, properly, and stop letting a platform generate SKUs for you.
2. Bundles and their components
You sell a kit of three parts. You also sell one of those parts on its own. The kit shows stock, the part shows stock, and neither knows the other exists.
Selling one kit has to hold three parts, the same way shipping one kit consumes three parts. If a bundle only reserves itself, every bundle you sell is a quiet oversell of everything inside it.
This one is worth checking on your own setup right now, because it is invisible until it fires and it fires on your best-selling kit.
3. The counter sale nobody recorded
A walk-in customer buys something, the money goes in the drawer, and the system finds out at the end of the day or never. For that whole period the marketplace has been selling stock that left the building hours ago.
No amount of channel synchronisation fixes this. If the shelf can change without the system knowing, nothing downstream of it can be correct.
4. Returns that came back to the shelf but not to the figure
A returned parcel is put back on the shelf by whoever opened it, and the figure is updated later, or not at all. This one does not cause overselling — it causes the opposite, which is why it goes unreported for so long. You stop offering stock you actually have, and the loss never shows up as a loss. It shows up as a product that stopped selling.
5. The sync interval itself
Even a perfect system talks to a marketplace on an interval. Between one update and the next there is a window where the platform's figure is stale. It cannot be closed to zero.
What it can be is small and known. A gap of a minute on a fast-moving SKU is a risk you have measured. A gap you have never measured is the one that surprises you.
The setting that makes you oversell on purpose
Most marketplace integrations offer a minimum quantity to keep showing — a floor, so a listing never drops to zero and loses its ranking and its reviews.
It is a real trade and plenty of sellers take it. Just be honest about what it is: when the floor is higher than what you actually have, you have chosen to accept orders you cannot fill. That is not a sync failure, and no amount of stock accuracy will prevent it.
Take the trade if the ranking is worth it. Do not take it and then wonder why you are still cancelling orders.
A checklist you can run this week
- Pick your ten fastest-moving products. Ignore the rest — the tail does not oversell.
- For each, count what is physically on the shelf, and write down what every channel is currently offering.
- Subtract. Any channel offering more than the shelf holds is an oversell waiting for a buyer.
- Check your bundles. Does selling a kit hold its components?
- Check your SKU codes. Is anything listed twice under two codes?
- Time your slowest channel update. Place a test order, see how long the other channels take to notice. Now you know the size of your window.
- Count the cancellations you caused in the last month, as opposed to the ones buyers caused. That number is what all of this is worth to you, and until you have it you are guessing at whether the problem is worth fixing.
Step 7 is the one to do first if you only do one. Most sellers have never separated the two, and the answer decides whether the rest of this list matters at all.
FAQ
What actually causes overselling?
A gap in time, not a mistake in counting. Between the moment an order is placed and the moment every channel's figure updates, the same unit is still on offer everywhere. Anything that widens that window — a slow sync, an unrecorded counter sale, a second listing under a different code, a bundle that does not hold its parts — makes overselling more likely.
Should stock be deducted when the order comes in?
No. Cancellations are normal, and a system that deducts at the order has to put the stock back on every one of them. Miss a single put-back and those units are lost from your figure with no error and no trail. Hold the stock as reserved instead, and take it off the shelf when the goods physically leave.
How do reservations work with bundles?
Reserving a bundle has to hold its components, because the components are what physically exists. A bundle holds no stock of its own — it is a way of selling other products together — so if one kit is ordered, the parts inside it must be held, or the same parts stay on sale individually.
Does syncing stock across channels stop overselling completely?
No, and anyone who says otherwise is selling something. An interval between updates always leaves a window. Good stock handling makes the window small, makes it the same everywhere, and makes it recover by itself when something fails. It does not make it zero.
Why does my available quantity not match what is on the shelf?
Usually because units are reserved for orders that have not shipped, which is correct and expected. If the difference does not match your open orders, you probably have phantom reservations from events that were missed — which is why reservations should be recomputed from open orders rather than adjusted one event at a time.
How Omnek handles this
Omnek keeps one master stock, and every channel's orders come off that one figure — marketplace orders and counter sales alike. There is no per-channel stock to keep in agreement with anything, because there is only ever one number.
Pending orders are held as reservations rather than deducted, so a cancellation costs nothing to unwind, and the held figure is recomputed from the open orders every time rather than adjusted event by event — a sync that fails repairs itself on the next run instead of leaving a phantom behind. Reservations sum across every source into one figure, so no channel can quietly erase another's hold. A bundle holds its components.
Returns come back through the returns desk, so a parcel that reaches the shelf reaches the figure at the same time.
Daraz gets the new figure without you typing it
When your free stock moves, the quantity on your linked Daraz listings is updated for you. No editing quantities by hand, and no afternoon where Daraz is still offering a unit that left this morning.
Before you switch it on, the stock page shows you what Daraz is showing now against what it is about to show, listing by listing, so you can see the size of the gap you have been carrying rather than find out afterwards. If a listing is refused, it says so and says why, instead of going quiet.
The keep-selling minimum is there per product if you want it — and it is described on that page as what it is, not as a feature with no cost.
Shopify
Shopify is built end to end — the connection, order sync, deliveries, COD and RTO — and it reads from the same master stock as everything else, so it is not another figure to keep in agreement with the first one.
It is opening to sellers shortly rather than today, and the app says so on the screens where you would go looking for it. We would rather be late and working than early and apologising.
Couriers, including the one you already use
Leopards and PostEx connect directly, using API credentials you generate yourself in the courier's own portal — the keys stay write-only once saved, so the app can use them and nobody can read them back out of it. TCS, Trax, M&P, BlueEx, CallCourier and Swyft are named in the app as not yet connected, because a list that quietly includes what is not built is how a seller finds out the hard way.
And the part that usually is not on offer anywhere: if you use a courier that is not on that list, we will build the integration for you. Most platforms hand you a fixed list and tell you to choose from it. Your courier relationship, your rates and your pickup routine are worth more than our convenience, so we would rather add yours than ask you to change.
Each channel has its own page with the whole picture: Daraz, Choice, Shopify and courier booking.