Your inventory number is a guess

Pick any product in your catalogue. Ask three systems what the stock level is. Warehouse, storefront, marketplace listing. If they agree, you are unusual.

Most commerce systems are not wrong about anything individually. They are wrong about when, and that turns out to matter enormously.

Where it actually goes wrong

The checkout race. Two people buy the last unit at the same moment. Both checkouts read one in stock, both proceed, and one customer waits four weeks for an item that never existed. This is a concurrency problem and no amount of dashboard accuracy fixes it.

Marketplaces caching your feed. You update stock centrally; three marketplaces hold yesterday's figure. You now have four sources of truth and a daily reconciliation job somebody maintains by hand.

Returns. The unit comes back, gets inspected, and might be resold. Meanwhile the available-to-promise number has already been decremented and does not come back until somebody reconciles it by hand.

The warehouse counts when they get round to it. Cycle counting is good practice and universally inconsistent, which means the number is exactly as good as the last count of the bin it came from.

The structural fix

One number, one owner.

Pick a single source of truth for available-to-promise. Everything else — the storefront, the marketplaces, the warehouse terminals — is a projection of it, updated from events rather than queried on the page. That is the whole idea, and it is less work than the reconciliation it replaces.

Then reserve rather than decrement. When a checkout starts, the unit is reserved against that order with a short expiry. If payment completes it converts to sold; if it does not, the reservation lapses and the unit returns to sale automatically.

That single change removes the oversell almost entirely, and it removes it at the point where it was happening rather than by detecting it afterwards.

What it costs

Honestly: it is not free, and anyone who tells you real-time accurate stock is cheap is selling something.

The work is in modelling stock as a reservation-and-release flow rather than a number you set, and in accepting that marketplaces will always be slightly behind. That last one is unavoidable — their platforms are eventually consistent and everyone knows it, so the design goal is "does not oversell", not "always exactly right".

What not to do

Do not buy a dashboard. A dashboard that shows your stock is accurate across four systems is a dashboard you will maintain by hand for the rest of your life, and it will be wrong within a month of nobody checking it.

Do not raise the safety margin either — holding more stock than you need to hedge against a sync problem is a working-capital cost that grows silently and shows up as a cash-flow problem long before anyone connects it to the checkout race.

How to tell which you have

Three questions:

1. Two customers bought the same last unit last week — has it happened?
2. How many stock adjustments did you make by hand last month?
3. When a marketplace says out of stock and your warehouse says nine, which do you believe?

The answers tell you whether this is a timing problem, a process problem or a modelling one. Each has a different fix and they cost very different amounts, which is why the first thing we do is work out which one it is rather than quote a rebuild.