The customer service team calls it "the apology email". The warehouse calls it "the phantom order". However you describe it, overselling is the moment your website, marketplace listing or shop till sells a unit that does not exist. It costs you the refund, the carrier fees, the goodwill and often the customer. It is also entirely preventable, because overselling is never a mystery. It is a data flow problem with a known set of causes.

Why retailers oversell

Four causes account for nearly every oversell I have investigated:

  • Sync delay. The channel publishes stock from a feed that is minutes or hours old. Two channels sell the last unit in the gap between feeds.
  • Unallocated buffers. No safety stock is reserved per channel, so a marketplace promotion can drain stock that the web team was counting on.
  • No reservations. Baskets hold stock visually but not in the system. Twenty customers can each have the last unit in their basket, and the site keeps selling it.
  • Multiple truths. The shop till, the ecommerce platform and the marketplace connector each hold their own stock figure, and none of them matches the warehouse.

The IMRG research programme, which tracks UK online retail operations closely, shows how thin the margin for error is when channels multiply. Every channel you add is another place where one of these four causes can fire.

The architecture that stops it

There is one architecture that eliminates overselling at the source: a single stock authority that every channel reads from and writes to. The ERP holds the total available stock, applies allocation rules per channel, subtracts reservations, and publishes the resulting sellable figure to each channel. When a channel sells, the sale returns to the ERP instantly and the sellable figures for every other channel are recalculated.

This is the difference between a connected operation and a collection of systems, and it is covered properly in running every sales channel as one business. The stock engine in the middle does not need to be complicated. It needs to be authoritative and fast.

Allocation and reservation rules that work

Allocation answers the question "who gets the next unit". The default rule, first come first served across all channels, sounds fair but ignores margin and strategy. Most retailers should allocate by channel priority, set in business terms: the channel with the best margin, the flagship store, or the marketplace contract that penalises non fulfilment.

Reservations answer the question "what is already spoken for". Three reservation types matter:

  • Open order reservations. Paid orders hold stock until fulfilment. This is non negotiable.
  • Basket reservations. Items in an active checkout hold stock for a defined window, typically 10 to 30 minutes.
  • Channel safety stock. A minimum quantity per channel that cannot be sold by other channels. This protects the web from a marketplace promotion stripping the shelf.

The subtle failure is the reservation that never expires. Stale basket reservations quietly tie up stock until the availability numbers drift down. Set expiry times, and make the expiry visible in reporting so it can be tuned. Stock levels that never look right are often a reservations problem wearing a counting problem disguise.

The marketplace problem

Marketplaces make overselling worse because they take your stock numbers and publish them without context. Amazon's listings reflect the feed you send, and the feed reflects whatever your connector thinks is available. If the connector syncs every hour, you have a one hour window where Amazon can oversell you. If it syncs daily, you have a day.

Marketplace connectors also handle their own inventory updates, cancellations and returns, which creates reconciliation work. The marketplace and ERP integration explains how to structure those connections so the marketplace reports back to the same stock authority instead of running its own version. The rule is the same as everywhere: the channel may sell stock, but it never owns the stock record.

Sync discipline and reconciliation

Even with the right architecture, sync failures happen. The discipline that keeps overselling rare is:

  • Near real time for sales. A sale on any channel must update the stock authority in seconds, not at the next batch.
  • Alerting on stale feeds. If a channel has not confirmed a sync in the expected interval, stop selling on that channel automatically rather than guessing.
  • Daily reconciliation. Compare channel sales against ERP postings each morning. The number of mismatches is the health metric for your whole integration estate.
  • Audit of adjustment codes. Manual stock adjustments are where truth decays. Every adjustment needs an owner and a reason code.

The Better Retailing coverage of independent UK shops shows how even small operators feel the same pressure when they sell through a till and a website from one back office. The scale differs, the failure mode does not.

Getting there without a rewrite

If you cannot replace systems today, you can still cut overselling sharply with three moves: introduce per channel safety stock buffers, switch sales feeds from batch to near real time where your connectors allow it, and reconcile channels daily instead of weekly. Those three changes alone remove the majority of oversells in most operations I have worked with.

Longer term, the fix is the connected architecture described in the unified record article article, where margin improves as a side effect of the same change. And when the board asks what the overselling problem is actually costing, the stockout cost analysis gives you the numbers to answer in pounds, not apologies.