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.

Vendor count — 22+ independent vendors sell multi-echelon / probabilistic safety stock across SAP, NetSuite and Oracle marketplaces — our own count from a five-marketplace scan, and the most-proven paid category that scan found
In our exact channel — Netstock and Smart Software explicitly list Microsoft Dynamics (AX, BC, 365, NAV) as supported ERPs on their own sites
The named platforms — ToolsGroup (SO99+, probabilistic), Slimstock (Slim4, MEIO), Blue Ridge (Replenishment Optimization) — all sell the same shape at enterprise price points

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:

Unsupervised write-back — The consequence: A wrong buffer is a real stockout or real trapped cash · Our rule: Every write is a proposal behind approval
Optimizing off the analytics copy — The consequence: BPA pre-transforms run on a 12-hour cycle — you'd optimize on a half-day-old position · Our rule: Read the transactional surface for the position
Running it on-premises — The consequence: Planning Optimization is not supported on-prem; the legacy engine is [DEPR] since March 2023 · Our rule: We qualify on-prem out — the buffer isn't the first problem
Confident forecasts on thin history — The consequence: Intermittent parts punish naive fits · Our rule: Croston's-type methods and an explicit "insufficient history" flag

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.

Inventory at cost — The balance sheet. Finance has it to the penny
Buffer share — the slice of that inventory held as safety stock — Step 1 of the Monday diagnostic below: value the minimum quantities across item coverage
Carrying rate — what holding stock costs you per year — Your finance team's standard rate. Every finance team has one
Premium freight spend — The freight ledger, with expedites separated from standard runs

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.

About Cognilium Cognilium is the AI optimization layer for Dynamics 365 — complementary apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Built on Power Platform, Dataverse and Azure. https://cognilium.ai · https://www.linkedin.com/company/37180269/

Worked example. Modelled from public documentation and typical operations.

Runs Dynamics and wondering what the last mile is worth on your data? Book a 15-minute call — we'll run the buffer diagnostic on a read-only extract and walk you through the numbers live, no deck. https://cognilium.ai

— Cognilium. We optimize the decisions your ERP can only manage.

Sources

Key takeaways

Safety stock in Dynamics 365 is a static minimum quantity on item coverage. Planning Optimization plans to it; nothing in the ERP recomputes it.

Demand planning forecasts the mean. The buffer is set by the variability around the mean — of demand and of lead time — a different distribution the ERP does not fit.

Realised lead times from actual PO receipts, not the configured lead time, are what size the buffer. The gap between the two is where the leak hides.

The optimized buffer belongs in the coverage fields the planning engine already reads, written back behind planner approval — not in a second system the engine never sees.

Common mistakes to avoid

Treating expediting and excess stock as two separate problems. They are usually two symptoms of one static buffer field nobody owns.

Buying a standalone inventory-optimization product whose output never reaches the fields Planning Optimization reads. The plan does not get better; the planner gets a second screen.

Optimizing from the analytics copy of the data. The pre-transformed position lags the transactional one by hours — read the transactional surface for anything a buffer depends on.

Letting an agent write planning parameters unsupervised. Every write-back is a proposal behind a planner approval step, or it is a production incident waiting to happen.

Your safety stock is a number someone typed in 2019