Your safety stock is a number someone typed in 2019

Open any Dynamics 365 released product, go to item coverage, and look at the minimum quantity. That number is your safety stock. Now ask one question: who set it, and when?

The usual answer: at go-live, by the implementation team, using a rule of thumb — because after go-live, nobody owns re-deriving it. Demand has moved since. Lead times have moved since. The number hasn't. It sits there managing your working capital by inertia.

This is the single most common inventory defect in a Dynamics shop, and it is invisible, because it never shows up as a system error. It shows up as expediting and excess stock — two symptoms nobody traces back to one static field.

What Dynamics does, precisely — and where it stops

Credit where it is due. Dynamics 365 Supply Chain Management manages inventory policy well.

Coverage groups and item coverage [GA] hold the per-item replenishment personality —

requirement, period, min/max, manual, DDMRP.

Planning Optimization [GA] — the current MRP engine, an in-memory service, fast enough to

run during office hours — nets demand against supply, pegs it, and fires action messages.

Demand planning [GA], a separate Power Platform app, forecasts the mean demand with

auto-ARIMA, ETS, Prophet, XGBoost and a best-fit selector.

Every one of those is real and good. And not one of them computes the right safety-stock number. Planning Optimization plans to the buffer you gave it. Demand planning forecasts the mean — but safety stock is a question about the variability around the mean, and about the variability of your lead time, which is a different distribution entirely.

That is the gap. The ERP records the buffer and enforces it. It does not optimize it.

Why this is the last mile, and why the money lives here

Safety stock is not a rounding error on the balance sheet. For a mid-market distributor it is often the largest single lever on working capital, and the second-largest driver of premium freight after genuine demand spikes.

The reason it is under-served is structural, not accidental. Microsoft optimizes for the median customer across every industry on one code base. A buffer computed for your demand profile, your lead-time variability and your service-level policy loses the median-customer argument every time. So it stays a static field — the process built out to the decision, and the decision itself left on the table.

That decision is the last mile of ERP, and it is a data-science problem: fit the distributions, target the service level, net it across the network. It is exactly the kind of decision the ERP records but cannot make.

This is a proven category, not a hunch

Before we talk about building anything, the honest market check: does anyone actually pay for this? Yes — more than for almost anything else in the ecosystem.

This category is proven. Netstock sells it into Dynamics today; ToolsGroup and Slimstock sell it across SAP, NetSuite and Oracle. We are none of them, and we make no claim to their results. What the incumbents structurally cannot do is the thing that matters most to a Dynamics buyer, which brings us to the design decision.

The design decision: write back into the coverage group, not into a second tool

Here is the opinion, and we will defend it. A standalone inventory-optimization tool is the wrong architecture for a Dynamics customer. Feature parity loses here.

The incumbent model is a separate SaaS product with its own login, its own data copy and its own UI. The planner now works in two systems, the numbers drift between them, and the "optimized" buffer lives somewhere the planning engine never reads.

The Dynamics-native model is the opposite. The optimizer writes the computed safety-stock value into the coverage-group and item-coverage fields Planning Optimization already reads. There is no second tool. The existing plan simply gets better. That is the whole differentiator, and it is only available to something built on the ERP's own substrate.

Concretely, the write-back goes through the ERP MCP server [GA] (the runtime surface an agent can call, live since January 2026) using data_update_entities, scoped by a purpose-built security role — and always behind a planner approval step. A bot never rewrites a planning parameter unsupervised.

The method, and the part of it we don't trust

The engineering is deliberately conservative. Inventory money rewards correctness over cleverness.

Demand distribution per SKU-location. For runners, standard statistical fits. For the long

tail of service parts that sell a handful of times a year, intermittent-demand methods (Croston's-type) — the same problem Microsoft's Demand planning tackles with Best fit model v3 [PP]. That feature is still in preview, so we compute it in the app and label it; we do not put a preview on your critical path.

Lead-time distribution from actual PO receipts. The configured lead time might be 14 days

while the last 40 receipts averaged 31. The variability, not the mean, sets the buffer.

Service-level target, costed. The planner sees the trade between service and cash, per SKU,

not a black-box number.

Multi-echelon netting across DCs, so a central buffer isn't funded three times over.

And the discipline that keeps it honest — the anti-patterns we design against:

What it's worth — the calculation you run on your own book

We will not quote you an inventory-reduction percentage. We have not measured one in your tenant, and any published benchmark is someone else's demand profile. What we will give you is the arithmetic itself: four inputs, where each one lives in your systems, and what to multiply.

The arithmetic, in words:

One-time cash released = buffer value × the share that rebalancing frees at the same blended

service level. That share is not a number to assume — it falls out of recomputing the buffers against your own demand and receipt history, which is what we do on a read-only extract.

Recurring saving = the released cash × your carrying rate, plus the slice of premium freight

that correctly buffered runners stop burning.

Against it: an app priced as a departmental line, not a per-seat one.

The reason to hand you the formula rather than a headline number: the formula is what you check against your own book. That check is exactly how we'd prove it — on your data, on a call.

What to do on Monday, without calling us

Open item coverage on your top 50 SKUs by value. Note how many share one minimum quantity, then

value those minimums — that valuation is the buffer share input to the arithmetic above.

Pull the last 40 PO receipts for your three worst-expedited parts. Compare the realised lead

time to the configured one — the size of that gap is what says a recompute will move the number.

If the configured number and the realised number are strangers, you have found the leak — and

you now have the read-only diagnostic you can run yourself.

Dynamics is your system of record. The optimal buffer is your system of intelligence. We build that layer — on your governed stack, writing back into the fields your planner already uses, and we never step on the partner who put your ERP in.

Your safety stock is a number someone typed in 2019