Demand & inventory optimization for Business Central
Business Central will replenish to the safety stock you typed in. It will never ask whether that number is right. Deriving what it should be 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. 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, and 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.
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.
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.
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.
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.
Questions
Common questions
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.
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.
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.
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.
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.
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
Business Central picks the lowest price you already entered. It never asks what the price should be.
Travel is roughly half of order-picking time. Where inventory lives decides how far anyone walks.
The supported integration surface, the security model, and what we do not touch.
The method, written up
How the buffer is computed, which data it needs, and where it is written back so the planning engine reads it.
Dynamics 365 can recalculate your safety stock. It still trusts the lead time you typed.
The safety stock journal recomputes minimum coverage from your own transaction history — over a window set by a lead time someone typed at go-live.
Read more7 min read
Dynamics 365 runs your MRP. Why is your inventory still wrong?
Master planning in Dynamics 365 is a calculation, not a decision. Microsoft ships the engine and leaves four replenishment-policy choices to you — coverage segmentation, safety stock method, forecast netting and time fences.
Read more11 min readDemand & Inventory Optimizer — solution showcase (reference build)
Reference build, not a delivered engagement: how a safety-stock minimum typed at go-live quietly becomes the number driving both overstock and stockouts.
Read more10 min readYour safety stock is a number someone typed in 2019
Safety stock in D365 is a static field the planning engine never recomputes. The mechanism behind the gap, and the read-only diagnostic that finds the leak.
Read more7 min read
If you run Dynamics 365 SCM on-premises, do you have a supported MRP engine?
You have a running master planning engine on-premises, and it is the deprecated one — Planning Optimization does not support on-premises deployments. What "supported" means for the engine you are left with is described three different ways across three Microsoft pages. Here is each wording, quoted, and what each of the three honest options costs.
Read more7 min readWhat can Planning Optimization actually not do in 2026?
Microsoft's fit-analysis page currently marks three rows as Future wave — sales line reservation using explosion, intercompany planning execution, and requirement types for skills, courses, certificates and titles. But that page answers a narrower question than the one people ask, four other Microsoft pages carry real limits it never lists, and on three features Microsoft's own pages disagree with each other.
Read more9 min readWhy does your MRP produce twelve thousand action messages?
Because the volume is an output of your coverage configuration, not a measurement of how wrong the plan is. Four settings decide the count, and Microsoft documents every one of them — coverage segmentation, negative days, the time fences on the master plan, and turning action messages off where the answer is always "do nothing".
Read more9 min readTime fence or time freeze — which one is deleting your planners' work?
Two features in the Dynamics 365 demand planning app have near-identical names and opposite jobs. A time fence stops people editing a forecast. A time freeze stops the recalculation overwriting what people edited. Only one of them is on by default, and it is not the one that saves your adjustments.
Read more7 min read
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.