Safety stock set at go-live is quietly costing you — the case for a decision layer on Dynamics 365

Somewhere in most operations teams there is a spreadsheet that gets rebuilt every Monday.

It holds safety stock and reorder points. Someone pulls the numbers out of the ERP, recalculates them from memory and gut, and pastes them back in. Every week. And when that person is on holiday, it does not happen — and something stocks out, or capital sits dead on a shelf.

That person is not the problem. The shape of the tools is. And it is worth naming exactly what is going wrong, because it is the same story in almost every business running Microsoft Dynamics 365 or Business Central.

The number was right once — at go-live

When your ERP went live, someone set a safety-stock level. It was probably reasonable at the time: a round number, a rule of thumb, a percentage of average demand.

Then the business moved on. Demand got lumpier for some SKUs and smoother for others. Lead times drifted. A supplier that used to ship in five days now takes twelve, and varies. But the safety-stock field did not move with any of it. It is a static value in a system that records everything around it changing.

The result is the quiet, two-sided cost of bad inventory:

• Too much — cash frozen in stock you did not need, warehouse space consumed, write-offs at the end of the season.
• Too little — stockouts, expedited freight, the order that went to a competitor because you could not fill it today.

Neither shows up as a line item called "safety stock was wrong." It shows up as thinner margin, and nobody traces it back to the field that never got updated.

Your ERP records the decision it cannot compute

Here is the frustrating part: your ERP already holds everything needed to set safety stock properly.

It has the demand history. It has the actual lead times and how much they vary. It has the service level you are trying to hit. The correct reorder point and safety stock are a calculation over exactly that data.

But an ERP is built to record and manage a process — to place the order, receive the goods, post the transaction. It is not built to derive the optimal decision inside that process. That is not a flaw in the ERP; it is simply a different job. So the calculation gets exiled to the Monday spreadsheet, done by hand, on a fraction of the data, once a week if you are lucky.

What a decision layer does instead

A decision layer sits on top of the ERP and does the one thing the ERP was never designed to do: the math.

For inventory, that means computing safety stock and reorder points from the customer's own demand history and real lead-time variability — per SKU, per location — and writing the recommendation back into Dynamics 365 for a planner to approve. Not once at go-live. On a schedule, as the data moves.

Three things make it something a team will actually trust and use:

• It runs on your own history, in your own environment — not a generic model of "how inventory usually behaves."
• A person approves every change. The system prepares the decision; the planner still makes it. That is by design, not a limitation.
• It never touches the ERP core. The layer reads the system of record and writes back through the platform's supported surface. Your implementation and the partner who runs it are untouched.

The planner's Monday changes: they approve a computed recommendation instead of rebuilding a spreadsheet. And the number stops being "right once, at go-live" and starts being right this week.

The same gap, everywhere the ERP records a judgement call

Safety stock is the clearest example, but it is not the only one. The identical pattern — the ERP records the decision but cannot compute it — shows up in pricing (the discount approved by rule of thumb) and in the warehouse (the pick path everyone knows is wrong but nobody can prove). They are all the same shape, and they all leak margin in the same quiet way.

If a decision in your operation is currently made by hand, in a spreadsheet, from an export, and it matters when it is right — that is exactly what a decision layer is for.

See how we build it on Dynamics 365 decision optimizers, or the inventory-specific version at demand and inventory optimization. If you would rather just talk it through, tell us the decision that is costing you and you will get an honest read on whether this is worth doing for you.