Overselling is not bad luck
The same stock is listed on your own store, Shopee and momo, and all three show "in stock". In reality one unit is left, all three sell it at once, and you spend the afternoon apologising.
How often this happens has nothing to do with luck and everything to do with how long a stock number takes to travel from one place to another. This article is about where that delay comes from and how to squeeze it out.
Why listing the same stock everywhere is hard
The problem is not listing. It is deduction.
After every sale, something has to tell the other channels that one unit is gone. Done manually, the best case is every few hours — and overselling only needs a window of minutes.
Three common approaches, with very different delays:
| Approach | Sync delay | Oversell risk | Labour cost |
|---|---|---|---|
| Manual periodic reconciliation | Hours to a day | High | High, grows with channel count |
| Fixed stock allocation per channel | None, but sacrifices sellable quantity | Low | Low |
| Single source of stock + automatic deduction | Seconds to minutes | Low | Low |
The cost of approach two: you fragment your stock
Allocating ten units per channel is intuitive and does prevent overselling. The cost is that every channel looks out of stock.
Split 30 units three ways and no channel can sell an eleventh unit, even with 20 sitting in the warehouse. Fast-moving items suffer most — exactly the items you least want unavailable.
Fine for low-volume lines. Not for anything that actually turns.
How approach three works
One idea: stock exists once, in the system. What channels display is a projection of it.
In practice:
- A channel sale happens; the platform sends a webhook, or the system polls for orders
- The system deducts from the matching warehouse and writes a movement record tied to that channel order
- The new sellable quantity is pushed back to every channel
The movement record in step 2 is what matters. Without it you cannot later explain why three units disappeared. With it, every deduction traces back to a source order — which is the only reliable basis for an audit.
Three things that bite in practice
Webhooks are not guaranteed. They get dropped and they get re-sent. So you need periodic polling as a backstop, and duplicate notifications must be recognised as the same event, or you deduct twice.
Returns must be added back, and they are much slower than shipments. Shipping takes minutes; a return can arrive two weeks later. In between the unit is neither in the warehouse nor sold, so stock state has to express "in transit" or the books will not reconcile.
Channel SKUs never match. The same item has three different IDs on three platforms. The mapping needs its own maintenance, including cases where one channel listing maps to several warehouse SKUs.
SynERP's Shopee integration follows this model: automatic deduction from the matching warehouse after each sale, with a traceable record for every movement.
Which step first
If you reconcile by hand today, you do not need full automation immediately:
- Consolidate stock into one record. Decide which system is the single source; everywhere else only displays. This is a process decision, not code.
- Automate the largest channel. One channel usually accounts for most of the work.
- Add the rest one at a time. With a single source in place, each additional channel follows the same pattern instead of adding mess.