Demand & inventory optimization for
Dynamics 365
Business Central will replenish to the safety stock you typed in. It will never ask whether that number is right. Safety Stock Quantity is an input field. MRP reads it, respects it, and plans supply to hold it — faithfully, every run. But the number itself came from a person, usually at go-live, and on most systems it has not been revisited since. Deriving what it should be needs the variability of your demand, the variability of your supplier lead times, and a service level you have actually chosen. That is a statistics problem, and it is the one we build for.
What Business Central does with inventory, and where it stops
Business Central plans replenishment properly. You choose a reordering policy per item — Fixed Reorder Quantity, Maximum Quantity, Lot-for-Lot or Order — set a reorder point and a safety stock quantity, and run MRP from the planning worksheet. The engine reads the net inventory position, compares it against open demand and your safety buffer, and suggests supply where there is a shortfall.
Microsoft's documentation is direct about what safety stock is:
Safety Stock Quantity is the minimum number of items you want to keep in inventory to handle fluctuating demand. It also acts as the reorder point if the reorder point quantity is not specified.
“The minimum number of items you want.” It is a declaration, not a calculation. MRP's job is to honour it, and it does that exactly. What no part of the planning engine does is examine whether the declared number matches the demand and lead-time behaviour the item has actually shown.
This is the manage-versus-optimize line again, and again it is not a criticism. Executing a policy consistently across thousands of items is the job of a system of record. Deriving the policy is a different job and was never in scope.
What setting the right level actually requires
Safety stock exists to absorb two kinds of surprise, and a good level is a deliberate trade between the cost of holding stock and the cost of running out. Four things decide it, and none is a field you can fill in from memory.
Demand variability
Not average demand — the spread around it. Two items with identical monthly averages need very different buffers if one arrives steadily and the other in occasional large orders.
Lead-time variability
The one most often ignored, because the ERP holds a single planned lead time. What matters is how much the actual receipt date moves around it, which is measurable from receipt history and usually larger than anyone expects.
A chosen service level
How often you are willing to be short. This is a business decision, not a statistical one, and it should differ between an item that stops a production line and an item a customer will wait a week for.
The cost of both mistakes
Holding cost against the cost of a stockout. Without both, “optimal” has no meaning — you can always eliminate stockouts by holding more, and always cut inventory by accepting more of them.
Each of these is estimated from history, and each moves as the history moves. A number that was right two years ago is not wrong because someone was careless; it is wrong because the world changed and nothing recomputed it.
Why the number is usually wrong, and nobody is at fault
Planning parameters are set during implementation, when there is no history to set them from. A reasonable value gets entered, often the same one across a whole item category, and the system goes live. From that day it works: MRP honours the parameter and the warehouse holds the buffer.
Nothing then triggers a review. There is no alert for “this item's demand pattern no longer resembles the one this buffer was sized for”, because the ERP has no opinion about what the buffer should be. The failure is silent and shows up as two symptoms that look unrelated: stockouts on items that should be safe, and a slow accumulation of stock on items nobody is worried about.
The parameter is honoured perfectly. That is exactly why nobody notices it is wrong.
How the Demand & Inventory Optimizer works
Four steps, in tandem with Business Central rather than beside it.
- 1
Measure what actually happened
Item ledger entries for demand by item and date, and actual receipt dates against purchase orders — which is what turns lead time from a planning assumption into a measured distribution. Read through the documented API and Dataverse; nothing leaves your tenancy.
- 2
Classify before forecasting
Separate items whose demand is smooth enough to forecast from those that are intermittent or lumpy. The second class does not respond to the standard safety-stock formula, and forcing it through one produces a confident number that is wrong.
- 3
Derive the parameters, per item
Compute safety stock and reorder point from demand variability, lead-time variability and the service level you chose for that item class. The output is the pair of numbers MRP actually consumes, not a forecast you would then have to translate.
- 4
Propose, with the delta visible
Write the proposed values back into Business Central alongside the current ones, with the assumed service level and the reasoning attached. A planner approves. The parameters MRP consumes remain parameters a human owns.
On your governed stack, not ours
Dataverse-native, running on Power Platform with Azure for the model workload, and shipped via AppSource where that suits your procurement. Your demand history and supplier performance stay inside your own tenancy.
We read and write through documented integration surfaces. The ERP core is not modified, so your upgrade path and your implementation partner's work are both untouched. For an IT buyer that is usually what decides it, and it is why we build this way rather than as an outside service with a nightly data export attached.
What we need, and what we will tell you
The requirement that decides whether this is worth doing is receipt history. Plenty of systems hold demand history and no record of when purchase orders actually arrived — and without that, lead-time variability has to be assumed, which is the single largest term in the calculation.
What makes this work
- Two to three years of item ledger history
- Actual receipt dates, not just planned lead times
- Current planning parameters, so the delta is visible
- A stated service level per item class
- Someone who owns the planning decision
When we will say no
- No receipt history, so lead time can only be assumed
- Demand is intermittent across nearly the whole catalogue
- Planning happens outside the ERP, in spreadsheets
- Nobody is permitted to change a planning parameter
We check this before proposing a build, and we say so plainly when the data cannot support it. A safety stock figure derived from history that cannot support one is worse than the number already in the field, because it arrives with the authority of arithmetic.
What this is not
- Not a planning system to run instead of MRP
- Not a change to the Business Central core
- Not a chart of stock levels to go and read
- Not silent overwriting of your parameters
- Not a reason to change implementation partner
- Not a shipped product with a user count to quote
A working demo exists and we build the app on request, against your data and your service-level policy. That is the honest state of it. When there are delivered engagements worth quoting numbers about, the numbers will appear here — and not before.
Common questions
Does Dynamics 365 Business Central calculate safety stock for me?
No. Safety Stock Quantity is a field you fill in. Microsoft's documentation describes it as the minimum quantity you want to keep on hand, and it also acts as the reorder point when no reorder point is set. MRP then plans replenishment to honour that number faithfully. What the system never does is ask whether the number is correct for this item, at this demand variability, with this supplier's lead-time behaviour. That derivation is a statistics problem, and it is the one we build for.
How is this different from the forecast we already run in a spreadsheet?
Mostly in what it produces. A spreadsheet forecast usually gives a demand number. The parameter your ERP actually consumes is a safety stock level and a reorder point, and getting from a forecast to those requires the variability of demand, the variability of lead time, and a chosen service level — not just the mean. The app computes the parameters MRP consumes, per item, and writes them back where planning will read them.
Do you overwrite our planning parameters directly?
Not by default, and not without a review step. The app proposes revised safety stock and reorder point values with the reasoning and the assumed service level attached, and a planner approves them. You can promote defined item groups to automatic updating later, once the proposals have been right long enough to trust. The parameters MRP consumes stay parameters a human owns.
What data does this need?
Item ledger history — demand by item and date, ideally two to three years so seasonality is visible — plus actual receipt dates against purchase orders, which is what makes lead-time variability measurable rather than assumed. Current planning parameters, so we can show the delta rather than a number from nowhere. And a stated service level per item class, which is a business decision rather than a statistical one.
What if our demand is genuinely unpredictable?
Then that is the finding, and it is worth having. Intermittent or lumpy demand does not respond to the standard normal-approximation safety stock formula, and forcing it through one produces a confident number that is wrong. Those items are better handled by a different policy, and the honest output is to say which items fall into that class rather than to give every SKU a figure.
Does this work on Finance & Operations as well as Business Central?
Yes. The statistics are identical; only the integration surface differs. Business Central through its API and Dataverse, Finance & Operations through OData data entities and Business Events. We lead with Business Central because that is where mid-market planning is most often run on parameters nobody has revisited since go-live.
The rest of the family
Pricing Optimizer
Business Central picks the lowest price you already entered. It never asks what the price should be.
Pick-Path & Slotting Optimizer
Travel is roughly half of order-picking time. Where inventory lives decides how far anyone walks.
All four Optimizers
What Dynamics manages in each domain, and what we optimize.
How we build inside the ERP
The supported integration surface, the security model, and what we do not touch.
Start with the receipt history
The first question is whether your data can measure lead-time variability at all. If it cannot, that is a useful answer and it costs you one call.
Last updated 2026-07-29