Omnichannel Inventory Visibility Problems: The 7 That Oversell and Hide Stock, and How to Avoid Them

Why does the point of sale feed turn out to be the whole project?

Availability is a calculation over events, and the highest volume source of events in a retail estate is the till. If stores sell and the ledger does not hear about it within seconds, store availability is a guess, and a guess is what produces both overselling and hidden stock.

What makes this specific to retail is that point of sale estates are almost never uniform. Stores acquired in different phases run different versions, franchise partners and concessions run their own systems entirely, and third party logistics providers and dropship vendors report on their own cadence. The flagship can publish in real time and a 2011 store cannot, and both are in the same availability query.

The failure pattern is a project scoped on the assumption that the estate behaves like the flagship. Design proceeds, the event ledger is built correctly, and then integration reaches the older stores and discovers an end of day export. At that point the choice is to delay, to accept batch for part of the estate, or to fund a till upgrade nobody budgeted.

The fix is to answer this in week one, before design. Ask, per store format and per system version, what event types can be published and at what latency. Then design for a mixed estate deliberately: real time where it exists, the best available feed elsewhere, and a per node freshness attribute the availability calculation actually uses, so a node with a stale feed carries a larger buffer automatically rather than lying with confidence.

What goes wrong when you seed the ledger from existing stock records?

An append only event ledger has to start somewhere, and the starting balance comes from your merchandising system. That balance is wrong, in the ordinary way that all retail stock balances are wrong, and the ledger will faithfully carry the error forward for as long as nobody counts.

The specific trap is that a ledger looks authoritative. Once availability is derived from events with timestamps and correlation identifiers, people believe it, including the people who used to treat the number with healthy suspicion. So a store that was quietly short forty units becomes a store that is confidently short forty units, and the short picks that follow damage trust in the new system rather than in the old count.

The second issue is unposted movement. At the moment you seed, there are receipts not yet posted, transfers in flight and returns in the back room. Seeding without a defined cutover point double counts some of it and loses the rest.

The pattern that works is to seed per node against a recent count rather than against the whole estate at once, define an explicit cutover timestamp per node with a freeze on postings across it, and run the new ledger in parallel with the existing feed before anything switches over. Then reconcile continuously from day one, with an exception queue, because divergence is inevitable and you want it visible rather than discovered at stock take.

Why do the merchandising, warehouse and returns integrations break after launch?

Each publisher has its own idea of what a transaction is, and the breaks come from that rather than from connectivity.

The merchandising system breaks around adjustments. Cycle counts, write offs and reclassifications arrive as balance corrections rather than as movements, and a ledger that treats a correction as a movement double applies it. Corrections need their own event type with the prior value recorded.

The warehouse system breaks around timing. A receipt is posted when the goods are booked in, which can be hours after they physically arrived and were already picked from. Available to promise computed off posting time understates during exactly the window when a promotion is live.

Returns break around condition and location. A returned unit is not sellable until it is inspected and put away, and returns systems frequently publish the return event before the sellable event exists, so the ledger adds a unit that no picker can find.

The fourth break is silent lag. Any of these feeds can slow without failing, and a slow feed produces overselling with no error anywhere. The fix in every case is to monitor end to end event lag per source as a service level with alerting, and to require named event types per system in the statement of work rather than a general claim about integration.

What happens when reservation expiry is not reliable at volume?

A reservation that never expires is invisible stock loss. The unit is neither sold nor available, no report shows it, and nobody notices for weeks. On a large catalogue leaked reservations accumulate quietly until a category looks short and a buyer orders replenishment against demand that was never real.

This fails specifically at volume and specifically at peak, which is the worst combination. Expiry implemented as a scheduled sweep is fine at ordinary load and falls behind during a drop, when reservation creation rates multiply and the sweep cannot keep pace. The stock disappears at the exact moment you needed it visible.

The second failure is a single reservation class. Basket holds, payment holds, collect orders, subscription replenishment and pre orders all have different lifetimes and different commercial meanings, and treating them as one object means the shortest sensible lifetime applies to all of them or the longest does. Neither is right.

The fix is reservations as first class ledger events with an explicit time to live per class, expiry that is enforced at read time as well as by a sweep so a stale reservation cannot suppress availability even if the sweep is behind, and a monitored count of active reservations by class and age. That count is the early warning. When the ninety minute bucket starts growing during a peak, you know before your merchandisers do.

Should you build custom or configure what you already own?

If you are replacing your order management system anyway, run a compact node network and have no violent peaks, buy. Fluent Commerce is built around exactly this event driven model and is a good answer at that shape, and you will be live sooner than a build. Kibo is reasonable for mid market. Manhattan Active Omni carries genuine depth and IBM Sterling Order Management has been running enterprise inventory for a very long time. There is no honour in building infrastructure whose rules you were never going to change.

Before commissioning anything, check whether your problem is the platform or the inputs. If your stores cannot publish sales in near real time and your counts are stale, no availability engine on the market will produce a number you can trust, and buying one is an expensive way to learn that.

Build when two or more are true. Your availability rules are genuinely commercial and change often, so a configuration ticket per change is a permanent tax on merchandising. You already run a distributed order management system you intend to keep and only need the inventory layer, which suite vendors do not sell cleanly. Your read volume or peak shape makes per call pricing on a hosted availability service a serious line item. Your node network includes concessions, franchise partners, third party logistics or dropship stock that vendor models handle awkwardly. Or you have raised buffers, know it costs more than it saves and cannot prove it.

How do hidden costs get into the quote?

The first is the number of publishing systems, which is almost always higher than the initial count. A merchandising system, three point of sale versions, a warehouse system, a returns platform and a dropship feed is six integrations, not two, and each has its own event semantics.

The second is peak design. Building for steady load and building for a drop that multiplies traffic in ninety seconds are different exercises, and load testing at your genuine peak concurrency is a deliverable with a cost attached. Ask for the test results, the failure mode and the rollback plan in writing.

The third is multi region, where read latency budgets across continents change the architecture rather than adding a server.

The fourth is reconciliation, which is permanent operating work rather than a build task. Someone has to work the exception queue every day, and if nobody owns it the queue becomes a graveyard and the ledger drifts.

The fifth is store counting discipline. A buffer that flexes with measured accuracy only works if accuracy is measured, which means a counting cadence and the labour behind it. That is an operations budget item that a software quote will not contain and the benefits case quietly assumes.

What separates an inventory visibility build that works from one that fails?

The first separator is vocabulary. Ask the developer to explain on hand, available to sell and available to promise and to say where reservations sit. If those three collapse into one number in the conversation, they will collapse into one column in the database and you will be back here in two years.

The second is an agreed staleness budget. Say it out loud and agree it commercially: two seconds on a product page is acceptable to almost every retailer and dramatically cheaper than zero staleness at the edge. Then monitor end to end event lag as a service level, because silent lag is what produces overselling during peak.

The third is whether buffers are a function rather than a constant. Measured accuracy for that store and category, days since last count, recent short pick rate and the commercial cost of a cancellation versus a lost sale. Stores with good discipline then earn smaller buffers and sell more, which creates the incentive no policy memo ever produced.

The fourth is that on hand is derived from events rather than stored as a mutable number, so when a store swears it had three and the system said zero you replay the ledger and get an answer in a minute.

The last is ownership. Availability underpins every order the business takes, and it should not live behind someone else's login. At Digital Heroes the client owns the repository, the cloud accounts and the event data from the first commit.