Why your stock numbers are always wrong

A retailer selling on a website, a marketplace and in a shop has one physical stock level and three systems with an opinion about it. They disagree, customers order things that do not exist, and somebody spends Monday morning apologising.

The usual response is to sync more often. That treats the symptom.

The actual problem

Peer-to-peer syncing means each system believes it is authoritative and pushes its view to the others. Two sales land in the same few seconds in different channels and both systems were right when they accepted the order.

No sync frequency fixes this. You can make the window smaller; you cannot close it while two systems both think they decide.

One authority, everything else asks

Designate a single system as the authority on stock. Every other channel asks it rather than keeping its own count, and reservations happen there.

Which system is less important than that there is exactly one. An ERP, a warehouse system, a purpose-built service — any works. Two do not.

Reserve at the basket, not at the invoice

Stock should be committed when a customer takes it, not when payment settles. The gap between the two is where overselling lives.

• Reserve on add-to-basket or at checkout start, with an expiry.
• Release the reservation if the basket is abandoned.
• Convert it to a deduction on payment.

This costs a little availability — reserved stock is briefly unsellable — and buys you never telling a customer their order is cancelled.

Keep a buffer for the channels you do not control

Marketplaces poll on their own schedule and will be stale no matter what you do. Holding a small buffer per channel is not a workaround; it is an honest acknowledgement that you cannot make a third party's cache current.

Make disagreement visible

Whatever you build will drift, because physical stock is affected by things no system sees: breakage, theft, miscounts, returns processed wrongly.

Reconcile on a schedule, and make the discrepancy a number somebody looks at. A system that silently corrects itself hides the operational problem causing the drift.

Where this sits in a build

Stock accuracy is usually the largest piece of genuinely custom work in a commerce project, and it is rarely what the brief leads with — the storefront is. That ordering is backwards more often than not.

More on the sector in our retail and e-commerce work, and on what it does to a budget in the e-commerce cost breakdown.

Why does my e-commerce stock keep going wrong?

Because several systems each believe they are authoritative and push their view to the others. Two sales landing seconds apart in different channels are both accepted, because both systems were right when they accepted them. No sync frequency fixes this — you can shrink the window but not close it while two systems both think they decide.

How do you stop overselling?

Designate a single system as the authority on stock and have every channel ask it rather than keeping its own count. Reserve stock when a customer takes it rather than when payment settles, with an expiry that releases abandoned baskets. Then hold a small buffer for marketplaces, whose caches you cannot make current.