AI inventory optimization for Business Central — dynamic where BC is static

Pre-launch — join the waitlist for founding pricing.

Last reviewed: 2026-05-21

Business Central’s inventory parameters are static fields on the Item card. Safety Stock Quantity is a number the planner typed once. Reorder Point is a number the planner typed once. Reorder Quantity and Maximum Inventory are numbers the planner typed once. Item Reordering Policy is an enum the planner selected once — Lot-for-Lot, Fixed Reorder Qty., Maximum Qty., or Order. Nothing in standard BC re-evaluates any of them as your demand pattern moves, your service-level math drifts, your lead-time history changes, or your warehouse mix shifts. Isovel makes each one adaptive — derived continuously from your live sales data and your live forecast — and writes the updated values back to the Item or SKU card so BC’s Planning Worksheet reads the current answer, not a number from 2024. No spreadsheet. No formulas to maintain.

15–25%

of inventory value per year is what carrying excess inventory costs you (storage, capital, obsolescence, insurance).

APICS Puget Sound Chapter — Cost of Carrying Inventory [1]

38%

excess inventory at SMBs — Netstock 2024 Inventory Management Benchmark Report (n=2,400).

Netstock 2024 Inventory Management Benchmark Report [2]

~90%

of spreadsheets contain errors — and BC's ABC analysis framework still asks you to do it in one.

Panko-derived industry estimate; EazyStock corroboration on BC ABC workflow [3]

Phase 1   Pre-launch waitlist. One-click install — listing coming to Microsoft AppSource. $999/month or $10,000/year (12-month commitment, ~17% discount). Fair-use limits apply for high-volume tenants.

What Business Central ships today

Business Central includes a complete inventory-parameter surface. The Item card carries Safety Stock Quantity, Reorder Point, Reorder Quantity, and Maximum Inventory as static fields, and the Item Reordering Policy enum — Lot-for-Lot, Fixed Reorder Qty., Maximum Qty., Order — tells the Planning Worksheet which calculation path to follow per item. [4] BC’s Stockkeeping Unit table is the per-location override layer for the same parameters, by Microsoft’s documented design: “If you plan for demand at different locations, we recommend that you define SKUs for each location and that all demand is created by using a value in the Location Code field.” [5]

Native ABC analysis exists too — Google’s AI Mode summarizes the scope accurately: “Standard Business Central implements the ABC framework natively through Cycle Counting Periods, but businesses frequently use built-in analytical tools, custom dimensions, or AppSource extensions to drive broader procurement and sales strategies.” [6] BC’s native ABC is count-frequency oriented — how often to physically count A items vs. C items — not a planning-policy driver.

Microsoft itself recommends ABC classification as the foundation for selecting reorder policy per item: “One best-practice foundation for selecting a reordering policy is the item’s ABC classification. When you use ABC classification, you manage items according to three classes.” [7] The best practice is published; the automation to perform the classification, apply it to reorder-policy selection, and keep it current as velocity shifts is not in scope of the BC-native surface.

Where BC’s inventory parameters go static

Three concrete gaps recur across Google AI Mode, Microsoft’s own documentation, the named BC ISV admissions, and operator threads on r/Dynamics365 in 2026. Each one is a place a real planner ends up working in Excel.

Safety stock is a static value

Google’s AI Mode publishes the wedge verbatim:

“Standard Business Central treats safety stock as a static value. It will not dynamically shift or adjust for seasonal trends out-of-the-box. If your item demand fluctuates throughout the year, you must manually adjust these quantities or utilize specialized demand forecasting apps from AppSource.” — Google AI Mode, 2026-05-21 [8]

Insight Works — publisher of the Enhanced Planning Pack, one of the most-installed BC inventory add-ons on AppSource — corroborates from the ISV side: “Microsoft Dynamics 365 Business Central uses fixed safety stock values added to reorder points to establish minimum stocking levels. Safety stock does not dynamically adjust automatically based on forecast changes within standard BC functionality.” [9]

EazyStock (owned by Syncron) describes the operational consequence: “Every planning parameter and reordering policy is static and has to be manually adjusted.” [10] The planner sets Safety Stock Quantity once. Nothing in BC re-sets it when seasonality, service-level targets, lead-time variability, or demand variance move underneath.

ABC native is count-frequency, not policy-driver

Microsoft’s own best-practice docs tell you to use ABC for reorder-policy selection. [7] BC’s native ABC implementation tells you how often to cycle-count A items. [6] Those are different jobs. The planner is left to perform the classification, apply it to the Reordering Policy enum on every Item or SKU card, and re-do the work as item velocity shifts.

EazyStock again, on the workflow this leaves the planner with: “To use Business Central’s ABC analysis framework, you first need to categorize your stock items into groups based on similar characteristics manually. This is typically done in a spreadsheet.” [11] A spreadsheet. With error rates estimated at roughly 90% on industry aggregator data. [3]

Reorder points don’t recalculate from the live forecast

Reorder Point is a value on the Item card. The Planning Worksheet reads it. Nothing in BC standard recalculates the reorder point when the forecast moves, when lead-time history shifts, or when the service-level math demands a different buffer. The planner re-evaluates it manually — usually after a stock-out or after carrying cost ramps obviously high. The 38% excess-inventory anchor — Netstock’s 2024 Inventory Management Benchmark Report on n=2,400 SMBs — is what the parameter treadmill looks like in aggregate. [2] Each static reorder point is a small, plausible decision the planner made on a particular day, accumulating across thousands of SKUs into a costly buffer the business is paying 15–25% per year to carry. [1]

What Isovel makes dynamic — safety stock, ABC, reorder points

Isovel runs the inventory math continuously on your BC data and writes the updated parameters back as the Item Reordering Policy values the Planning Worksheet then reads.

Dynamic safety stock per SKU, per location, per service-level target. The agent computes safety stock from your service-level target and your forecast variance, recalculated continuously as demand patterns, lead-time history, and service-level targets shift. The number on the Item or SKU card is the agent’s current answer, not a value the planner set in 2024 and forgot to revisit. The 14-week and 26-week windows you would otherwise sweep through manually are handled in the background; the planner sees the current safety stock, the rationale for the current value, and the delta from the previous setting.

Automatic ABC + XYZ Forecastability classification. ABC by revenue, margin, or velocity (your selection); XYZ by forecast variance — the second axis of the classification grid that StockIQ, EazyStock, and a generation of forecasting tools have used to separate the items the forecast can be trusted on from the items the forecast can’t. The agent derives both axes. No spreadsheet, no manual classification, no quarterly re-run. The result writes back to the Item or SKU card as the Reordering Policy and parameter settings Microsoft’s own best-practice docs say should follow from ABC. [7]

Reorder points, reorder quantities, and maximum inventory that recalculate from the live forecast. When the forecast moves, the reorder point moves. When lead-time history shifts, the buffer adjusts. When carrying cost on a slow-mover crosses a threshold, the maximum inventory steps down. The agent updates Reorder Point, Reorder Quantity, and Maximum Inventory on the Item or SKU card together — they are interdependent fields and BC’s Planning Worksheet reads them as a set. The planner sees what changed and why, with the rationale string visible on every line.

All three transformations write back to BC. The agent updates the planning-parameter values (Safety Stock Quantity, Reorder Point, Reorder Quantity, Maximum Inventory) on the Item or SKU card and selects the matching Item Reordering Policy enum value (Lot-for-Lot, Fixed Reorder Qty., Maximum Qty., or Order) per item per location based on the ABC + XYZ classification. The Planning Worksheet then reads the updated parameters and policy exactly as it would read planner-typed values. Every write-back is approval-gated by default, idempotent (re-runs never duplicate writes), reversible within a 24-hour rollback window, and audit-logged. The trust primitives — pause, stop, rollback, restore manual approval — are permanent; the agent’s autonomy is graduated as the planner gains comfort with its track record.

Transparent, auditable, and reversible are non-negotiable when an agent writes back to an ERP of record.

Multi-location stock rebalancing

MVP Tier 0

Per-location safety stock, per-location service level, per-location demand pattern, and per-location stock all feed the same agent. When stock sits in one warehouse while another runs short, the agent recommends a transfer — sized to close the imbalance without depleting the source, rationale attached so the planner can audit the reasoning before approving.

The cross-source signal in 2026 BC buyer research is unmistakable. Google’s AI Mode summarizes the visibility primitive BC ships today: “Multi-Warehouse Visibility: Track real-time item availability across various geographical locations and transit hubs.” [13] Visibility is necessary but not sufficient. None of the named ISVs in the BC inventory-AI cluster — EazyStock, Insight Works, StockIQ, Netstock — claims algorithmic multi-location rebalancing as a published capability. The category gap is structural.

Multi-location reasoning surfaces automatically when the tenant has two or more locations — no toggle, no setup wizard, no per-location configuration.

For the closed-loop story — how a multi-location signal becomes a transfer-order draft line in BC — see /multi-location-inventory-rebalancing/ and /for-business-central/replenishment/.

Sporadic, slow-moving, and dead-stock surfacing

The long-tail problem in mid-market BC distribution is rarely the high-velocity A items — those almost manage themselves with reasonable defaults. The carrying-cost damage hides in three other buckets, and the agent surfaces each one explicitly.

Sporadic items — intermittent demand patterns where long gaps separate orders. Conventional moving-average safety-stock math gets this wrong in both directions. Isovel identifies sporadic patterns directly and treats them as such, with service-level math that accounts for the intermittency rather than smoothing it away.

Slow-movers — items with a clear velocity decay over a configurable window. The agent surfaces them before the reorder point catches up with the new demand reality, with a recommended action (mark down, redistribute, change policy class) and the rationale.

Dead stock — zero-velocity items still on hand, consuming carrying cost. Each surfaces in the planner UX with the cumulative carrying cost to date and a recommended disposition.

Each of the three buckets gets a rationale string the planner can audit, not a black-box recommendation. The Reordering Policy class and the safety-stock value the agent has set tell the planner what the agent currently believes; the rationale tells the planner why.

Connects via BC’s documented entry points — Microsoft-complementary by construction

Microsoft itself defines the two AI surfaces inside BC explicitly:

“Copilot is an AI-powered assistant that helps you work more efficiently by sparking creativity, boosting productivity, and eliminating tedious tasks. Copilot works collaboratively with you. You initiate actions, and Copilot provides suggestions, analysis, and assistance to help you complete them faster.”

“Agents are autonomous AI workers that can independently handle tasks with minimal human input. They automate specific processes, becoming a valuable member of the team where their work is transparent, reviewable, and keeps people in the loop as work progresses.” — Microsoft Learn, AI in Business Central [15]

Isovel slots into Microsoft’s own taxonomy as the supply-chain-planning agent — transparent, reviewable, and keeps the planner in the loop, by design. Microsoft’s published Agent surfaces in BC are scoped to other domains (Sales Order Agent, Payables Agent, invoice processing); supply-chain planning is open in Microsoft’s framework, and that is where Isovel sits. For the broader category framing, see agentic supply chain planning.

The connector authenticates via Office 365 SSO and uses BC’s documented OData and Web Services surfaces. No new database. No migration. Sales orders, item ledger entries, locations, vendors, and lead-time history flow into the agent within minutes of connect. Updated Item Reordering Policy values flow back out in the same idempotent, audit-logged path Isovel uses for all write-back.

Replaces the Enhanced Planning Pack (Insight Works)

The Enhanced Planning Pack from Insight Works is the BC-native incumbent on dynamic safety stock — Google’s AI Mode cites their dynamic-safety-stock article directly in the AI Overview citation set for business central safety stock. The capability they offer is “user-defined formulas for calculating planning parameters such as safety stock and reorder points based on current forecast information.” [16] The planner authors the formula. The pack runs it.

Isovel does not ask for a formula. The agent computes the safety stock and reorder-point math itself, per SKU per location per service-level target, and writes the updated values back. The shift from user-defined formula authoring to agent-derived continuous parameter math is the wedge — and the inventory-AI surface is the natural place to land it. The head-to-head — formula authoring vs. agent derivation, parameter pack vs. closed-loop agent — lives at /alternatives/insight-works/.

Coexistence is not the design point. Both products would otherwise write to the same Item Reordering Policy fields on the Item or SKU card. Isovel’s onboarding detects EPP and walks you through disabling it before write-back is enabled.

Why EazyStock, StockIQ, and the Enhanced Planning Pack aren’t this

The BC inventory-AI competitor landscape has three named functional incumbents besides Isovel.

EazyStock (Syncron) — parameter automation in a separate planning app. Their published positioning, verbatim: “In contrast, EazyStock calculates all orders automatically and continuously adjusts the parameters that drive recommendations.” [17] The trade-off they name themselves: “It’s time-consuming to set up; you need to calculate all planning parameters outside of Business Central and port them back in.” [10] Auto-tune the inputs the BC worksheet consumes; the planner still operates the BC worksheet, and now also operates EazyStock’s separate planning surface. Isovel removes the outside-of-BC step — agent, decisions, write-back all live inside BC’s planning context.

StockIQ — the closest functional name overlap on the feature set this page claims. StockIQ explicitly markets “Time-Phased Safety Stock (Seasonality etc), Automatic ABC Classification, XYZ (Forecastability) Classification, Sporadic Item Detection, New Item Exception Tracking, Dead and Slow Moving Inventory Detection, Warehouse-Level Stock Mix Optimization by Budget” for Business Central. [18] Strong feature surface. The category difference: StockIQ is a separate planning app — its surface is a browser app outside BC, the planner reviews StockIQ’s recommendations and executes them in BC. StockIQ’s published positioning expects operator-led algorithm configuration as part of onboarding. Isovel ships BC-embedded, closed-loop write-back to the Item card, and no algorithm to tweak.

Insight Works Enhanced Planning Pack — “user-defined formulas for calculating planning parameters.” [16] The planner still authors the formula; the agent doesn’t.

The cluster’s published positioning describes three flavors of helper on top of BC’s inventory parameters — parameter-automation helper, recommendation-engine helper, formula helper. Isovel is the agent that derives the parameters and writes them, with the planner’s approval and audit trail in place.

Watch dynamic safety stock recalculate on your BC data — read-only for 30 days. Get early access →

Business Central inventory AI FAQ

1. Does Isovel replace BC’s safety stock and reorder point fields? The fields remain in BC. Isovel computes the values — Safety Stock Quantity, Reorder Point, Reorder Quantity, Maximum Inventory — and writes them back to the Item or SKU card continuously. Where appropriate, the agent also updates the Item Reordering Policy enum (Lot-for-Lot / Fixed Reorder Qty. / Maximum Qty. / Order) per item per location based on ABC + XYZ classification. BC’s Planning Worksheet and Requisition Worksheet then read those values and that policy exactly as they would read planner-typed entries.

2. Does Isovel automate ABC classification? Yes — and XYZ Forecastability. ABC is derived from revenue, margin, or velocity per your selection; XYZ from forecast variance. The classification updates as your sales data shifts. BC’s native ABC framework (Cycle Counting Periods) handles count-frequency; Isovel handles the planning-policy-driver layer Microsoft’s own best-practice docs recommend. [7]

3. Can I customize the service-level math? Yes. The default service-level target is set per ABC class (for example, A items at 98%, B items at 95%, C items at 90%) with operator override available per SKU or per location. The agent computes safety stock from the service-level target and your live forecast variance — recalculated continuously as your data shifts.

4. Does Isovel work alongside Microsoft Copilot for Business Central? Yes. Microsoft’s own May 2026 Copilot for Business Central FAQ states that “some features, such as sales and inventory forecasting, use specific machine learning models. These features rely on Azure AI and aren’t related to Copilot.” [19] Microsoft’s ai-in-bc page explicitly distinguishes Copilot (collaborative assistant) from Agents (autonomous AI workers). [15] Isovel is the supply-chain-planning specialist agent in Microsoft’s own taxonomy.

5. How does Isovel surface dead and slow-moving stock? Velocity decay detection identifies items with declining sales velocity over a configurable window; dead-stock surfacing flags zero-velocity items still on hand. Each surfaces in the planner UX with the cumulative carrying cost, a rationale string, and a recommended action (mark down, redistribute, change policy class). The planner approves or defers; the agent does not auto-execute disposition actions.

6. Does Isovel reason about transfers between locations? Yes. Cross-location transfer recommendations are first-class output: per-location forecast, per-location stock, per-location service level, and lateral demand drive the recommendation. See /multi-location-inventory-rebalancing/ and /for-business-central/replenishment/ for the closed-loop story.

7. What about items with intermittent or sporadic demand? Sporadic-item detection identifies items with intermittent demand patterns (long gaps between sales) and applies Croston-class intermittent-demand math rather than treating them as zero-demand items. The service-level math accounts for the intermittency directly; the rationale string explains the policy class the agent has assigned.

8. Which versions of Business Central does this work with? Business Central 25, 24, and 23. Cloud (SaaS) at launch; on-premises is on the roadmap. The connector authenticates via Office 365 SSO and uses BC’s documented OData and Web Services surfaces.

The math the agent runs is the math BC distributors are already doing by hand

Dynamic safety stock, ABC velocity, forecastability scoring, reorder-point recalculation against the live forecast — every transformation the agent makes on a BC Item or SKU card is something a real BC mid-market planner is already doing in a spreadsheet on a quarterly cadence, between stock-outs and carrying-cost spikes. The agent removes the spreadsheet, runs the math continuously instead of quarterly, writes the updated values back to the Item Reordering Policy fields BC’s Planning Worksheet reads, and surfaces a rationale string for every value it has changed so the planner can audit the reasoning before the agent’s write-back lands.