Why your stock count is wrong in three places at once

A retailer with a website, two marketplaces and four stores has six opinions about how many of an item exist. The website says three, the marketplace says one, the store system says five, and the actual shelf has two. Everyone knows the numbers are wrong. The oversells, the cancellations and the marketplace account-health penalties follow from there.

The usual response is to sync the systems to each other. That is the decision that guarantees the problem is permanent.

Why syncing channels to each other fails

Peer-to-peer sync between four systems is six connections, each with its own latency, failure mode and idea of what a SKU is. There is no authority, so when two disagree there is no correct answer — only the most recent write. Under concurrent orders that produces exactly the oversells you were trying to prevent, and it does it worst at peak, when several channels sell the last unit inside the sync window.

If no system is authoritative, the stock figure is whatever wrote last. That is not a source of truth; it is a race condition with a dashboard.

One ledger, many channels

The shape that works: one inventory ledger that owns the truth, and every channel reads an allocation from it rather than holding its own count. Physical movements — receipt, sale, transfer, return, adjustment, damage — are recorded as events against that ledger, and the on-hand figure is derived rather than stored and edited.

Deriving the balance from movements rather than mutating a number is the single most important decision here. When a count is disputed, and it will be, you can show the movements. With a mutable field you can only assert a figure.

Allocation is the part people skip

One hundred units on hand does not mean one hundred available to sell everywhere. Some are reserved for orders not yet picked. Some are held for a wholesale commitment. You may deliberately expose a buffer to a marketplace where a stockout is penalised harder than a lost sale.

Allocation rules — per channel, per location, with a safety buffer — are where a retailer's commercial judgement lives, and they need to be configuration your merchandising team can change, not logic buried in an integration.

Reordering without a forecasting model

Demand forecasting gets pitched constantly and is rarely the right first investment. Rule-based reordering, done properly, captures most of the value and everyone can understand why it did what it did.

• Reorder point calculated from actual consumption rate over a trailing window, per SKU per location — not a number typed in two years ago.
• Lead time taken from what suppliers actually delivered, not what they promised. This one change surfaces the supplier who is consistently a week late.
• Safety stock scaled to demand variability and lead-time variability, so erratic items carry more cover and predictable ones carry less.
• Purchase suggestions raised automatically and approved by a person, with the reasoning shown.
• Slow-moving and dead stock surfaced before it becomes a markdown decision made under pressure.

This is explainable arithmetic, and explainability matters more than accuracy here, because a buyer who does not trust the suggestion will override it every time and you will have bought nothing.

The catalogue problem underneath

Half of what looks like an inventory problem is a product data problem. The same physical item exists as three SKUs because it was created separately for each channel, with different titles and no shared identifier. No inventory system can reconcile that, because as far as it can tell they are different products.

One product master, with channel-specific presentation derived from it, is the fix. Deduplication of the existing catalogue is slow, mostly manual, and the least popular part of any such project — and skipping it means the new system inherits the old confusion.

Returns, where margin quietly disappears

Returns are usually handled by a person deciding case by case, with no consistency and no record of why. The result is refunds issued on items that should have been rejected, resaleable stock written off, and no data on which products or which suppliers are driving the volume.

A rules-based triage — refund, inspect, reject — with reason codes captured properly turns that into something measurable. Not a model: an explicit rule set your operations lead owns and adjusts. Within a quarter it will tell you which SKUs have a returns problem, and that is usually a listing or sizing problem rather than a product one.