Demand & Inventory Optimizer — solution showcase…

The Demand & Inventory Optimizer

You hold too much of the wrong stock and still stock out on the parts that matter. The number driving both is one static field in Dynamics — a safety-stock minimum someone typed at go-live and nobody has recomputed since demand and lead times moved.

Cognilium builds the Demand & Inventory Optimizer — a companion app that computes the optimal safety-stock level per SKU per location and writes it back into your Dynamics coverage groups. This is a reference build: the architecture, the method, and the arithmetic on a modelled distributor. It is what we build, how we build it, and where you must not trust it.

Pillar: P5 — the last mile is where the money is. One line: Dynamics manages your inventory policy. We optimize the number inside it.

The problem, in the buyer's words

"We hold too much of the wrong stock and still stock out on the parts that matter."

Every distributor and every parts maker lives this. The slow movers are over-buffered and the runners are under-buffered, and the two problems hide each other on the balance sheet.

Ask the operator where the safety-stock number comes from and the answer is always the same: a minimum quantity someone typed at go-live and nobody has revisited since. Demand moved. Lead times moved. The number didn't.

Why Dynamics only manages it — the last mile

Dynamics 365 does the great majority of this well, and we say so plainly.

Stores the replenishment policy on the coverage group and item coverage — The safety-stock value is a static minimum quantity — set once, not computed
Runs Planning Optimization — nets demand, pegs supply, fires action messages — It plans to the number you gave it. It does not work out the right number
Ships Demand planning [GA] — auto-ARIMA, ETS, Prophet, XGBoost, best-fit — It forecasts the mean. Safety stock is about the variability, not the mean
Supports time-phased min/max keys, DDMRP buffers [GA] — Someone still has to decide the buffer. The methodology is native; the decision is not

So the record is complete and the decision is missing. That gap — the optimal buffer per SKU-location, recomputed as demand and lead time drift — is the last mile. It is a data-science problem, and it is where the working capital and the stockouts actually live.

We never touch the ERP core. Planning Optimization stays the engine. We compute a better number and hand it back through the supported surface. Your implementation partner keeps the ERP; we surround it with intelligence.

This category is proven — it is not a bet on demand. Netstock sells inventory-optimization apps into the Microsoft Dynamics channel; Slimstock (Slim4), ToolsGroup (SO99+) and Blue Ridge sell the same shape across SAP, NetSuite and Oracle. Idea-harvest counts 22+ independent vendors across five marketplaces doing multi-echelon safety stock — the most-proven paid category in the whole scan (idea-harvest.md #24). We are none of those vendors, we make no claim to their results, and we do one thing they structurally cannot: write the answer back inside Dynamics, with no second system to log in to.

What the Optimizer does, and the architecture

It runs on the same governed substrate the ERP already trusts — Power Platform, Dataverse and Azure, delivered through AppSource. One integration pattern, three moves.

The real D365 hooks — named, so you can check them:

Item coverage / coverage group data entities — What we read / write: The safety-stock minimum quantity, coverage code, negative/positive days · Status: [GA]
PO receipt history — What we read / write: The realised lead-time distribution per item-vendor — not the configured single number · Status: [GA]
Sales / issue transactions, InventSum on-hand — What we read / write: Demand history and current position per SKU-location · Status: [GA]
Planning Optimization connector — What we read / write: The plan we improve — we feed it a better buffer; it stays the engine · Status: [GA]
ERP MCP server — data_find_entities_sql (from 10.0.48), data_update_entities — What we read / write: The joins in one call; the governed write-back, scoped by a purpose-built security role · Status: [GA] 2026-01-27
Business events on the planning run — What we read / write: Trigger a recompute when the plan runs, not on a timer · Status: [GA]
Dataverse / Fabric — What we read / write: The feature store and the model outputs — Dataverse-native, inside your estate · Status: [GA]

Nothing here is an F&O code customisation on the ERP core. The extension is a connector; the intelligence ships as a governed SaaS app. That is why it surrounds Business Central and Finance & Operations alike — both resolve to the same substrate.

The data-science method — and where you must NOT trust it

The method is deliberately boring, because inventory money rewards correctness, not cleverness.

Fit a demand distribution per SKU-location — not a point forecast. For fast runners, standard statistical fits. For the long tail of service parts that sell twice a year, intermittent-demand methods (Croston's-type) — the same problem Microsoft's Demand planning addresses with Best fit model v3 [PP]. We do not wait on a preview: we compute it in the Optimizer and label it plainly.
Fit a lead-time distribution from actual PO receipts, per item-vendor. The configured lead time is 14 days; the last 40 receipts averaged 31. The variability is the whole game.
Set the buffer to a service-level target, per SKU-location, costed — so the buyer sees the trade between service and working capital, not a black-box number.
Net it multi-echelon across the DCs, so a central buffer isn't paid for three times.
Write the number back through Planning Optimization's own fields, behind a planner approval step.

Where it must not be trusted — stated before you ask:

Let the model write to coverage fields unsupervised — Why: A bad buffer is a real stockout or real cash tied up · What we do instead: Every write is a proposal behind an approval workflow. A bot never rewrites a planning parameter on its own
Optimize off the analytics copy — Why: Business performance analytics pre-transforms run on a 12-hour cycle. Optimizing on a half-day-old position is optimizing on the wrong number · What we do instead: We read the transactional surface for the position, the analytics/lake for slow signals
Run it on an on-premises deployment and expect the plan to improve — Why: Planning Optimization is not supported on-premises; the legacy engine has been unsupported since March 2023 [DEPR] · What we do instead: We qualify this out. If you're on-prem, the buffer isn't your first problem
Trust a service-part forecast with three data points — Why: Intermittent demand punishes naive fits · What we do instead: Croston's-type methods, and an explicit "insufficient history" flag rather than a confident wrong number
Believe our percentages — Why: We have not run this in your tenant · What we do instead: The arithmetic below is modelled. The real numbers come from a run on your extract (see the CTA)

A worked example — a modelled 14,000-SKU distributor

Take a mid-market automotive-parts distributor — around 14,000 active SKUs, three DCs, live on Dynamics. This is a worksheet, not a result. We have deliberately left the figures blank, because ours would tell you nothing about your operation and a number we invented would be quoted back at us as though we had measured it. What the table gives you is the shape of the arithmetic and, for each line, where in your own systems the number actually lives — which is usually the harder half.

Two of the inputs are judgement calls rather than lookups: the share your buffers are over-set (A4) and the share of expedites driven by buffer misses (A7). We size both from your extract on a diagnostic; until then, run the table with a pessimistic figure and a generous one and see whether the range still justifies the work.

A1 — What to measure: Inventory at cost · Where the number comes from: Dynamics on-hand valuation
A2 — What to measure: The buffer portion of it · Where the number comes from: Sum of minimum coverage x item cost
A3 — What to measure: Carrying rate per year — capital, storage, obsolescence, insurance · Where the number comes from: Finance owns this one; it is rarely on a report
A4 — What to measure: Cash released by rebalancing buffers to a per-SKU-location target, at the same blended service level · Where the number comes from: A2 x the share your buffers are over-set
A5 — What to measure: Annual carrying saving on the released stock · Where the number comes from: A4 x A3
A6 — What to measure: Premium-freight and expedite spend today · Where the number comes from: AP, freight GL, stockout-coded lines
A7 — What to measure: Expedites avoided by correctly buffering the runners · Where the number comes from: A6 x the share driven by buffer misses
A8 — What to measure: Recurring annual benefit · Where the number comes from: A5 + A7

Now the cost side, so the return is net, not gross:

C1 — Cost line: Optimizer subscription · How it is sized: Quoted per tenant, billed monthly
C2 — Cost line: AI run cost · How it is sized: Compute per SKU-location per week. At this catalogue size it is a rounding error next to C1, and we show you that arithmetic
C3 — Cost line: One-time read-only diagnostic · How it is sized: Fixed fee, credited against year one

Net: subtract C1 to C3 from A8. Two things decide whether the answer justifies the work — the size of your inventory base, and how far the buffers have drifted since anyone last recomputed them. Both come out of the diagnostic, and neither is a number we can guess for you.

Payback on the subscription is measured in weeks, not quarters. For comparison, a NetSuite Demand Planning module is quoted at $18k–$36k/yr and Microsoft SCM Premium lists at $300/user/month — the Optimizer is priced against a departmental line, not a per-seat one, because charging per user would punish you for letting more planners see the optimized number.

The signature verb, made literal: Dynamics manages the buffer. We optimize it.

How we'd prove it on your own data

We do not ask you to believe the table above. We build the Optimizer that is demonstrable on your data before the one that is impressive on ours.

Read-only extract. Item coverage, coverage groups, 24 months of sales/issue history, and PO receipt history. No write access, no integration to stand up, no change to your ERP.
We run the diagnostic in a sandbox and hand back a ranked list: the SKUs where the static buffer is costing you cash, the SKUs where it is costing you service, and the modelled £ on each — your numbers, computed with you in the session.
You decide whether the write-back is worth turning on. If native Dynamics is genuinely enough for your mix, we will tell you so — that is the wedge that earns the next conversation.

Any figure that comes out of that run is your number, measured with you. We never quote it back afterwards as a Cognilium result.

The call to action

Book a 15-minute call and we'll walk you through it live. On the call we run the Demand & Inventory Optimizer for you — and if you bring a read-only extract of your item-coverage and receipt history, we'll show you on your own numbers exactly which buffers it would change. Your SKUs, your numbers, one working session, written findings. We don't publish a demo or hand you a login — the live walkthrough is the proof.

Not on this exact Optimizer in a customer tenant yet — we're early on it deliberately. What we can do is get you on a call, run it against your data, and let you judge it on your numbers, not our logos.

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.

Demand & Inventory Optimizer — solution showcase (reference build)