What 'in stock' means when you sell on nine channels

A unit sells on eBay at 14:02. Your warehouse still has it on the shelf at 14:02, so the count is not wrong. What matters is when Amazon, OnBuy, Etsy and your own store find out that it is gone. If any of them learn about it at 14:20, you have an eighteen-minute window in which the same physical unit is advertised as available in eight places.

That window is where overselling comes from. It is not a counting failure, and no amount of stock-taking closes it.

Why the window opens

Most multichannel setups are built on scheduled syncs. A job runs every fifteen minutes, reads the stock table and pushes a number to each channel. It works, right up until two channels sell the last unit inside the same fifteen minutes.

Sellers usually respond by shortening the interval. Every five minutes instead of every fifteen. That reduces the window without closing it, and it multiplies API calls against marketplaces that meter them. eBay will rate limit you long before the window reaches zero.

The other common response is a buffer: hold back two units on every SKU so the overlap is absorbed. That works, and it costs you two units of sellable stock on every line you carry. On a 12,000 SKU catalogue that is a lot of inventory kept deliberately invisible.

What a single pool changes

The alternative is to stop treating each channel as holding its own number. One product record, one available figure, and every channel reading from it rather than receiving a copy of it on a timer.

When the eBay sale lands, the available figure drops once. The push to the other channels is triggered by that change rather than by the clock. The window becomes however long the marketplace API takes to accept the update, which is seconds rather than minutes.

It also means the buffer becomes a choice rather than a workaround. Some sellers still hold one unit back on fast-moving lines, because a marketplace can be slow to acknowledge. That is a deliberate decision about risk, not a patch over an architecture problem.

The part people forget: allocation

Available is not the same as on hand. A unit that is picked but not dispatched is still physically in the building, and it is not sellable. Neither is a unit allocated to an order waiting on a payment, or one reserved against a dropship request.

If your stock figure is on-hand rather than available, you will oversell even with instant sync, because you are publishing a number that includes units already promised to somebody. This is the single most common cause of overselling in setups that have already fixed their sync timing.

The figure that goes to a channel should be on hand, minus allocated, minus anything reserved, and it should be calculated at the moment it is asked for rather than stored and refreshed.

Multi-warehouse makes it a routing question

Once stock sits in more than one location the question changes again. A channel does not care which warehouse holds the unit, but you do, because the wrong one adds a day and a transfer cost.

The practical answer is to publish the total across the locations you are willing to ship that channel from, and decide the location at pick time rather than at listing time. Deciding it at listing time means republishing every time stock moves between sites, which is a lot of API calls to say something the buyer does not need to know.

What to check in your own setup

Three questions will tell you where you stand. First, when a unit sells on your busiest channel, what triggers the update to the others: the sale, or a timer? Second, is the number you publish on hand or available after allocation? Third, if you hold a buffer, do you know what it costs you in stock that is never offered for sale?

If the answers are timer, on hand, and no, your oversells are not bad luck and they will not be fixed by counting more often.