← All guides

Finding dead stock before it eats the open-to-buy

Inventory & replenishment · 8 min read

Neglected grey clothing rack with cobweb in a store corner beside bright shelves of neatly folded colourful garments

Dead stock rarely announces itself. It accumulates one quiet week at a time: a line that sold steadily, then slowly, then not at all — while the shelf, the stock value, and in many setups the reorder logic all carry on as if nothing changed. By the time it is obvious on the shop floor, the money has usually been spent twice: once on the stock that stopped moving, and again on the new stock the open-to-buy could not fund because the first lot never cleared. Finding it early is a data job, and Business Central with LS Central holds everything needed to do it — provided the review runs as a standing routine instead of an occasional tidy-up.

What dead stock actually costs

The stock value on the shelf is the visible cost, and for most stores it is not the largest one. Dead lines consume shelf and storage space that faster-moving lines could use, which quietly caps the sales the same square footage can produce. They add to every cycle count and stocktake, because staff count units that will still be there next count. They distort reporting: availability looks healthy, inventory value looks healthy, and the open-to-buy looks smaller than it should because so much of it is frozen in lines that will convert back to cash slowly, at a markdown, or not at all. Worst of all, a dead line with live replenishment settings can keep ordering. Under the Stock Levels calculation in LS Central replenishment, when stock on hand falls below the reorder point and a maximum inventory is set, the system orders back up to the maximum — the worked example in the LS documentation has a maximum of 20, a reorder point of 10, and stock of 8 producing an order of 12. That is correct behaviour for a live line. For a dead one, it is an automated leak in the buying budget.

Build the candidate list from system data

Start with movement, not with walking the shelves. A practical candidate list combines four signals, all available from item and ledger data:

Run the list by location, never only at company level. Location-level visibility changes the answer: a line that looks dead across the chain may be overstocked in one store while another store still sells it, and that is a transfer problem, not a markdown problem. Stores not yet working from system reports can run the same logic manually — a spreadsheet aging list built from last-sale date, quantity on hand, and cost per item-location — but the fields and the window must match the system version, or the two lists will argue with each other.

Triage: dead, seasonal, new, or just in the wrong store

A candidate list is not a markdown list. Every line on it gets one of four verdicts before anything is discounted:

VerdictTestAction
Genuinely deadNo sales past the category window, no season ahead that historically revives it, counted stock matches the systemDisposition: markdown, bundle, return, or clear — and switch off its replenishment
SeasonalNo sales now, but the line's selling season is still ahead and it sold in that season last cycleHold. Judge it after its season, not during the off-season
New lineStill inside its launch window; received recently and not yet given a full selling cycleHold. A new line judged on a dead-stock window is a buying mistake made twice
Wrong storeDead in this location, moving in anotherTransfer first. Discounting chain-wide for one store's overstock gives away margin on stock that would sell at full price elsewhere

Velocity context sharpens the call. Compare a line's sales rate against its forecast, its category average, and its own history. A line selling at a fraction of the category rate with stock covering many months at that rate belongs on the candidate list even if its last sale was recent — the no-sale window alone would have missed it, and coverage is what connects the list to the open-to-buy: months of cover on a slowing line is budget already spent.

Verify before marking down: the identification procedure

  1. Generate the candidate list by location using the no-sale window, aging band, and value-at-risk sort for the category.
  2. Apply the triage verdicts — dead, seasonal, new, wrong store — and record the verdict per line. Lines with no verdict do not proceed.
  3. Count the surviving dead candidates. Use the physical inventory journal, which calculates the expected quantity so staff can enter the counted quantity and post the difference. Cycle counting periods let high-value categories be counted more often than the rest, which suits exactly these lines.
  4. Reconcile surprises before acting. If the count finds materially less than the system shows, the problem is shrinkage or a recording error, and the markdown decision waits until the quantity is honest. Clean data first: decisions built on a quantity nobody verified repeat the original buying error.
  5. Decide disposition per line: transfer, markdown, bundle with a moving line, return to vendor where terms allow, or clear and block. Record the decision next to the verdict.
  6. Fix the replenishment settings in the same session (next section), so the line cannot quietly refill while its disposition is under way.

What success looks like: every candidate line carries a verdict, a counted quantity, and a disposition decision; the value at risk on the list is falling month over month; and no line marked dead has a live reorder point still able to order against it.

Stop the refill: replenishment settings for flagged lines

Identification without this step is a recurring chore instead of a fix. In LS Central, replenishment for recurring items runs through replenishment journals — the purchase journal creates purchase orders for stores and warehouses, and the transfer journal creates transfer orders between them — driven by each item's replenishment data. The calculation types include Average Usage, Manual Estimate, Stock Levels, and Like-for-Like, and they share the reorder point and maximum inventory fields described earlier. For a line with a dead verdict: remove or zero the reorder point and maximum inventory, or take the item out of the replenishment calculation for that store, so the next journal run cannot resurrect it. For a wrong-store verdict, the transfer journal is the tool rather than the enemy — moving the stock to the store that sells it is a replenishment action. For seasonal holds, leave the settings alone and set the review date for after the season; changing settings on a line that is merely out of season creates the opposite problem in three months. Where a line will never return, blocking the item for the affected store closes the loop so it cannot be reordered, transferred in, or sold from stale POS data by mistake.

Make the whole cycle a standing report on a fixed cadence — monthly for most categories — rather than a project someone runs when the shelves feel full. Dead stock accumulates at a steady rate in any store that buys broadly; a steady detection rate is the only version of this that stays ahead of it, and each run gets faster because the verdicts from the last run carry forward.

FAQ

How long without a sale makes a line dead? There is no universal number. Ninety days is a common first flag, 90 to 180 days a common formal window, with shorter windows for trend-driven goods and longer ones for durables. The right window is per category, documented, and applied consistently.

The system quantity and the shelf disagree. Which one decides? The shelf, after a count. Markdown and disposition decisions need a verified quantity; counting first also surfaces shrinkage while it is still small enough to investigate.

Should slow lines be discounted straight away? Not before triage. A line that is dead in one store and moving in another should be transferred, a seasonal line should be held for its season, and only the genuinely dead verdict earns a markdown as the first move.

IndexBack to all guides →