Why fresh shrink doesn't move after a replenishment upgrade

When an order recommendation is wrong, the first instinct is to interrogate the forecast: tune the model, adjust safety stock, check the ad data. Most forecasts in grocery do need more dynamic modeling, but the forecast is only one input to the plan.

Inventory is another, and in fresh it is the one most likely to be off. Most replenishment upgrades bring two things: a better forecast and an exception-based workflow. Neither one fixes the on-hand number both of them depend on. A better forecast doesn't help if the order is built on a wrong on-hand number. The order is still wrong, and the gap between the plan and the shelf stays open.

Inventory records in grocery are commonly off. Center store feels it less because a longer shelf life means the item doesn't go to waste while the record catches up. Fresh doesn't get that luxury. A wrong number can become shrink or an empty shelf inside 48 hours. The foundation deserves the same scrutiny as the forecast and the workflow.

Where the on-hand number stops being true

Perpetual inventory (PI), still the basis of many replenishment systems, breaks down at every step of the supply chain. Anyone who has run a fresh department will recognize the list.

• On the dock: A different variety shows up. The case size in the item master says 12 and the box holds six.

• In the back: Product moves between receiving, the backroom, and the floor without being scanned in.

• On the floor: Culls, sampling, and mis-scans pull product out of the department with nothing recorded. A package change moves meat from one SKU to another without the system of record changing.

• During prep: Fresh-cut, deli, and bakery production consume ingredients the ordering system still counts as on the shelf. A chuck roll becomes five retail items at yields that change by cutter and by day.

The workflow is only as good as what's underneath it

To reduce the counting that PI depends on, many systems have turned to exception-based workflows: the replenishment system flags the handful of items that need human review. To do that, the system has to decide which items need attention by comparing what it believes is in the store to what it expects to sell. If the belief is wrong, the filter is wrong with it.

Any forecast running on a PI system, or on a correction layer on top of PI, starts from a disadvantage. And inventory issues aren’t the only input the workflow inherits. Most systems don't consider that:

• Shelf life is treated as a fixed attribute, when it should change by vendor, season, and lead time

• A markdown sale reads to the forecast like full-price demand, when it should read as too much supply

• An out-of-stock reads like weak demand, when it should read as not enough supply

Each of these inputs shapes both the inventory balance and the final order, and each one needs a system that can understand more than a sales history and a running balance.

This is why a workflow change alone tends to disappoint. Counting and ordering may get faster, but overrides increase, and the shrink number doesn't move.

The fix is a new AI-powered record for on-hand inventory, along with data foundations that clean the inputs and map how an item transforms as it moves through the supply chain.

What changes when the foundation is right

An AI data foundation for grocery does the work a perpetual record assumes someone else did:

• Estimates on-hand from evidence, with store input where it matters. What shipped, what sold, what was culled or pulled for production, the counts store teams enter, and a shrink model that tunes itself per item and per store, so the estimate stays close to the shelf without a count every day.

• Directs the count to where it changes the order. The system knows which items it is least sure about, such as a bulk item whose case size just changed, a SKU with three weeks of questionable scans, or an ingredient that production draws down, and sends someone to those.

• Brings in the inputs the plan was missing. Shelf life estimated live per item. Markdown sales separated from full-price demand. Out-of-stocks read as lost supply, not weak demand. Item IDs harmonized across systems so a case on the dock and a scan at the register are the same product.

With that foundation underneath it, the exception-based workflow does what it was meant to do. The items on the list are the items that need human review. An order writer stops second-guessing the list because shelves are full and the backroom is light. The plan and the shelf converge because the plan is finally built on the shelf as it is.

How to evaluate your current system

Three signals, each reading a different part of the problem:

1. Override rate, by department. How often store teams change the recommendation. This is the symptom: it says whether the order writer trusts the output, without saying why.

2. Count versus screen. How often a physical count disagrees with the on-hand the system shows. This is the cause: it isolates the inventory error from everything else that can drive an override, like a forecast miss or a display change.

Key takeaways

• When the plan is wrong, the fix is usually upstream in the inputs, not only in the planning logic

• Inventory records are wrong across the store; fresh is where the error costs the most

• Exception-based ordering is the right workflow, but is not the only fix needed

• The store shouldn't be the system of record for on-hand; the system should build it and direct counts where they matter

• Override rate, count-vs-screen disagreement, and who decides what gets counted tell a team whether their system is working