Multi-channel inventory management: one stock pool, four places selling it

You have 40 units of one product. Amazon is selling it, so is your Shopify store, so is eBay, and so is the shop. Four systems, four order streams, one physical shelf.

Nothing on that shelf knows about the other three channels. Every one of them will happily sell the fortieth unit at the same moment, and each will be correct according to what it last knew.

That is the whole of multi-channel inventory management: the stock is one pool and the truth about it is distributed, and every problem in this category is a consequence of that. This page covers why the obvious fix does not work, the specific way marketplace fulfilment breaks the model, and what to insist on from a system.

Why syncing is not the answer people think it is

The instinctive fix is to sync stock levels between channels, and every tool in this space advertises exactly that. It helps, and it does not solve the problem, for a reason that is structural rather than a matter of product quality.

Sync is not instant, and cannot be. A channel is told your level, then it sells, then it tells you, then you recompute, then you tell everyone else. Even when each step is fast, there is a window in which two channels both believe the last unit is theirs. Marketplaces rate-limit updates, some poll on a schedule rather than pushing, and the busiest minute of your day is exactly when the queue is longest.

So the real design question is not "how do we keep everything in step" — you cannot, entirely — but where the truth lives and how you behave in the window.

The answer to the first half is that one system has to be the master, and it must not be a sales channel. If your Shopify store is the master and Amazon sells four units, Shopify finds out second-hand. A neutral system holding the pool and publishing to all four channels is the only arrangement where every channel is equally downstream.

The buffer, and why it is a tax

The universal workaround is a buffer: hold back a few units per channel, or publish a level lower than you have, so the sync window has slack.

It works. It is also a permanent cost, and it is worth being clear-eyed about what it costs.

A buffer of three units per line across a thousand lines is three thousand units of stock you have paid for and are refusing to sell. On slow lines that is most of your holding. Buffers also interact badly with marketplace algorithms — a listing that regularly shows low or zero stock is demoted, so the buffer that protects you from overselling also suppresses the sales you were protecting.

The honest position: buffer the lines where an oversell is genuinely expensive — high-velocity lines, marketplaces where a defect rate matters, anything with a delivery promise — and do not buffer the long tail. A single global buffer number is the setting everyone uses and nobody should.

The six numbers

The reason a spreadsheet cannot do this is that "how many do I have" is not one number. A system worth having tracks at least these separately, and one of the builds in our own build-off tracked exactly this set:

On hand — physically in your possession.
Reserved — promised to orders not yet shipped.
Sellable — on hand minus reserved. This is the only number that should ever be published to a channel.
On order — bought from a supplier, not yet arrived.
In transit — moving between your own locations.
At partners — held by a 3PL or a marketplace's fulfilment network.

Publishing on-hand rather than sellable is the single most common cause of overselling in multi-channel operations, and it is a design error rather than a sync problem. The stock is not wrong; the wrong quantity is being broadcast.

One further detail worth insisting on: when you promise more than you hold, sellable should go negative rather than clamping to zero. A zero looks like a calm, normal out-of-stock. A minus nine tells you that nine customers are going to be disappointed and somebody needs to decide which ones.

Marketplace fulfilment breaks the single-pool model

This is the part that catches people out, and it applies to any marketplace that also stores and ships your goods — Amazon's FBA being the obvious case.

Stock you have sent into a marketplace's fulfilment network is physically not yours to allocate any more. You cannot ship it to a Shopify customer. It is on hand in the sense that you own it, and it is not sellable through any channel except that marketplace.

Which means it is not one pool. It is a pool per fulfilment location, and the honest model is:

Stock in your own warehouse — sellable through every channel you ship yourself.
Stock at the marketplace — sellable only through that marketplace.
Stock at a 3PL — sellable through whatever channels that 3PL fulfils.

The consequences follow immediately. Your Shopify listing must be driven by your own-warehouse figure, not the total. Moving stock between pools takes days and has to appear as in-transit rather than vanishing. And a decision to send more into the marketplace is a decision to make it unavailable everywhere else, which is a genuine trade rather than a logistics detail.

Any tool that shows you a single company-wide number for a product that is split this way is telling you something true and useless.

Listings are the other half of the problem

Stock is the half everyone thinks about. The other half is that the same product has a different identity on every channel.

Different identifiers, different titles, different category structures, different image requirements, different variant models — one channel's size-and-colour matrix is another's separate listings. The mapping between your internal SKU and each channel's identifier is the thing that makes stock sync possible at all, and it is where the silent failures live: a SKU mapped to the wrong listing means you are decrementing one product and selling another, and the numbers will look fine until a count.

Two practical rules. Your SKU is the master identity, and every channel identifier is a mapping to it rather than a replacement for it. And bundles and multipacks need explicit component mapping — selling a three-pack has to decrement three units of the single, and a system that treats the multipack as its own product will drift permanently.

Counting stock that is in three places

Every inventory system eventually has to answer to a physical count, and multi-channel makes that harder in a way single-location retail does not prepare you for.

You cannot count it all at once. Your own warehouse you can count. Stock sitting with a marketplace or a 3PL you cannot — you can only compare your figure against their report. So a stocktake here is two different activities: a physical count for what you hold, and a reconciliation for what somebody else holds.

Reconcile against partner reports on a schedule, not annually. Marketplace and 3PL inventory reports routinely disagree with your own figures — units lost, damaged in their warehouse, misrouted, or returned by a customer and never put back into sellable condition. These are usually recoverable, and most fulfilment agreements have a claims process with a time limit. A discrepancy you find eleven months later is a discrepancy you are keeping.

Monthly is a reasonable cadence for most sellers. What you are looking for is not a perfect match but a trend: a line that is consistently short at one partner is a different problem from a one-off.

Cycle count rather than shutting down. A full stocktake means stopping sales, which multi-channel makes expensive because you cannot easily stop four channels at once. Cycle counting — a slice of the catalogue each week, weighted towards high-value and high-velocity lines — gives you a rolling picture without ever closing.

Count into a session, not over the top of the number. The rule that applies in every stock system and matters more here: a count is a session that opens, records what was found against what was expected at the moment it opened, is reviewed, and is committed as movements with a reason. If counting overwrites the on-hand figure directly, you have destroyed the movement history that would have let you explain the variance — and with four channels selling during the count, the variance is exactly what you need to explain.

Decide what a discrepancy means before you find one. Shrinkage, damage, mis-picking, a bad SKU mapping and an unrecorded return all present identically as "fewer than expected". Distinct reason codes on the adjustment are what turn a year of counts into a diagnosis rather than a number.

When you need a system for this

You do not need one for two channels and low volume. A person checking twice a day genuinely works, and it is cheaper than software.

You need one when:

You have oversold more than once, and it was not a counting error.
You hold buffers you resent — stock you are refusing to sell to protect against sync lag.
Somebody reconciles channels by hand. That person is your inventory system.
Stock is split across fulfilment locations, especially if a marketplace holds some.
You cannot answer how many of a SKU you can sell right now without opening three tabs.

Buy or build

Buy. For a standard multi-channel retailer this is a solved category and there are mature tools. The three questions that decide it: does it treat marketplace-held stock as a separate pool, does it publish sellable rather than on-hand, and what does a full export contain.

Build when your allocation policy is genuinely yours, when you hold stock in an arrangement the tools do not model — consignment, made-to-order alongside stocked lines, supplier-held stock you can sell — or when the tools that fit your complexity are priced for businesses much larger than yours, which is a real gap in this market.

Six systems were built from a single specification by three coding models; five run as live demos. The audits are the useful part, because none of the differences was a missing feature:

The strongest tracked all six quantities across two locations and two channels, and its channel connections admitted when they were not connected instead of pretending — which matters enormously here, because a sync that has silently stopped looks exactly like a sync that is working.
One recorded every reserve, ship and cancel as a movement that could be undone, and made changes atomic so an operation either fully happened or did not happen at all. A partial write during allocation is how one unit gets reserved to two orders.
One showed you exactly what would change before you confirmed it.
One, as delivered, existed only in the browser: no server, nothing saved, no real sign-in, and refreshing the page wiped every change. It had the best-looking dashboard of the set.

That last one is the warning for anyone evaluating a build or a cheap tool on a demo. The presentation layer is the easy part and it is the part you are shown.

The checklist

Show me sellable, and which quantities produced it.
Where does marketplace-held stock appear, and can a non-marketplace order allocate against it?
Oversell deliberately. Does the figure go negative or clamp to zero?
Stop a channel connection. How long until somebody is told?
Show me a bundle decrementing its components.
Show me the SKU-to-listing map for one product across every channel.
Move stock between locations and find it while it is in transit.
Export everything, and check the channel mappings came with it.

Check four is the one that separates tools that work from tools that appear to. A sync that fails loudly is a minor operational event; one that fails quietly is a week of overselling.

Ecommerce order management system covers the order side of the same problem — allocation, routing, the state machine and returns. If you are still deciding which category of product you need, what is a warehouse management system draws the line between warehouse, inventory and order systems. And if the stock lives in a shop rather than a warehouse, what a retail inventory management system includes is the counted inventory for that shape.

If you are building, the Ecommerce Inventory planner is the specification we hand our own agents — and it is the one planner we publish without a cited feature ledger, flagged unverified, because its research is a machine first pass we have not finished checking. The audit findings above are measured; the market counts are not ready, so we do not print them.