Shared Stock: Preventing Overselling Across Multiple Stores

Shared stock is a model that distributes the same physical product across several stores and deducts from a single pool when a sale happens. Writing separate stock to each store is the shortest path to selling the same item twice. Shared stock closes that risk at pool level.

How exactly does overselling happen?

List the same product as 10 units in two stores and the system shows 20 units as sellable. The warehouse holds 10. The first 10 sales pass fine; the 11th order falls on a product that cannot be shipped and gets cancelled.

On slow-moving products this fault stays invisible for a long time. It surfaces all at once on a campaign day — the error detonates at the worst moment, on your highest-volume day.

The cost has three layers: cancelled revenue, the effect of a seller-caused cancellation on your performance score, and the effect of that score drop on product visibility. Because the third is delayed, it is rarely connected to its cause.

How does a shared stock pool work?

The pool is the single source of truth for physical stock. Stores display a view of it; none holds its own stock.

When a sale occurs in one store, the pool decreases and the visible stock in the other stores updates in the same operation. The situation where "two stores each show the same 10 units as 10" becomes structurally impossible.

The critical point: the pool must live in your system, not on the marketplace. If the source of truth sits on the marketplace side, there is no answer to which number is correct.

Which distribution rule should you choose?

There are three common approaches, and the choice depends on product turnover.

Full sharing. Every store sees the whole pool. It delivers the highest sales potential because no store is artificially restricted. The risk is timing: simultaneous orders in two stores can collide inside the synchronisation delay. On slow-moving products that risk is low.

Proportional allocation. A set percentage of the pool is reserved per store. It reduces collision risk but also caps sales potential: one store's allocation can run out while another's sits unsold.

Safety buffer. Part of the pool is never exposed, absorbing API delay. This is the safest option for fast-selling products and campaign items.

Practical advice: do not apply one rule to the whole catalog. A safety buffer usually works better on fast movers, full sharing on slow ones.

How large should the safety buffer be?

The buffer should cover the units that could sell inside the synchronisation delay. A rough calculation:

Safety buffer ≈ Peak-hour sales rate × Synchronisation delay

For a product selling 6 units per hour at peak with a 2-minute delay, the theoretical need is under 1 unit. So a buffer of 1–2 units is enough for most products; an oversized buffer locks up sellable stock for nothing.

Campaign days are the exception: the sales rate multiplies and the delay can grow too. Raising the buffer temporarily before a campaign and lowering it afterwards is a reasonable pattern.

Should you open a second store on the same marketplace?

Some sellers open a second store on the same marketplace for a different brand or segment. Shelf space grows; so does stock risk.

The decision rests on one question: does the second store sell from a different product pool? If so, risk is low. If it will share the pool, opening it before setting up shared stock produces overselling on the first busy day.

Setup order

1. Match the catalog. Records of the same physical product across stores must be linked by barcode or SKU. Skip this and the pool will merge the wrong products.
2. Run a physical count. The pool's starting value must equal reality; a wrong start corrupts every later calculation.
3. Define the pools. Usually one product family equals one pool.
4. Choose a distribution rule and try it on a limited set of products first.
5. Watch the first week. If overselling occurs, raise the safety buffer; if stock sits locked for nothing, lower it.

If barcode matching is wrong, shared stock creates more problems than it solves. That is why step one cannot be skipped.

For using the module inside the product, see the shared stock guide; for general stock setup, see the warehouse and stock management article.