AI demand forecasting for Business Central — built to decide, not just to forecast

Pre-launch — join the waitlist for founding pricing.

Last reviewed: 2026-05-20

The forecast isn’t the bottleneck. The decision is. Business Central ships a complete forecast surface — the Sales and Inventory Forecast extension wraps Azure AI on top of your sales history and lands a forecast in the Demand Forecast Entry table for the Planning Worksheet to read. That surface was scoped to give the planner a place to think; the deciding work — distributing across locations, handling sparse and seasonal items, writing back replenishment lines — stays with the planner. Isovel registers as the external forecast engine via Microsoft’s own Sales and Inventory Forecast Setup entry point and takes that work on: per-location forecasts, automatic promo and seasonal detection, and replenishment recommendations that land back in BC as draft purchase orders and Requisition Worksheet planning lines for your approval.

49%

of expedited orders are caused by inaccurate demand forecasts.

APQC Open Standards Benchmarking via Supply & Demand Chain Executive [1]

55%

of SMBs report holding at least 20% excess stock — up from 48% in 2024.

Netstock 2025 State of Supply Chain Planning Report [2]

≥5

historical periods required before Azure AI in BC will return a forecast — long-tail SKUs are excluded by design.

Microsoft Learn — Sales and Inventory Forecast extension [3]

Phase 1   Pre-launch waitlist. One-click install — listing coming to Microsoft AppSource. Connects via the BC Sales and Inventory Forecast Setup external-engine entry point.

What Business Central ships today

Business Central includes a complete demand-forecasting surface. The Sales and Inventory Forecast extension wraps Azure AI on top of your BC sales history and produces a forecast that lands in the Demand Forecast Entry table for the Planning Worksheet to read. [3] The forecast page is the planner’s entry point; the Sales and Inventory Forecast Setup configures the engine.

Importantly, Microsoft itself architected the surface to accept external engines. The Sales and Inventory Forecast Setup exposes an external-engine connection point — a BC operator on r/Dynamics365 in 2026 confirmed the pattern verbatim: “you can point the forecast to any external engine you want in the Sales and Inventory Forecast Setup.” [4]

That permission is the install path for Isovel. BC’s data model and the Demand Forecast Entry table are the foundation; the engine that fills them is your choice.

Where BC’s forecast stops

Three concrete gaps recur across community.dynamics.com threads, Microsoft’s own documentation, and r/Dynamics365 in 2026. Each one is a place a real planner ends up working in Excel or Power BI.

Multi-location forecasts are aggregated, not distributed

Microsoft’s documentation states the Sales and Inventory Forecast extension “produces aggregated forecast for all locations” — the planner “must distribute amounts afterwards.” [3] A BC distributor with three warehouses gets one number per SKU and has to re-allocate it across locations by hand, every refresh. Multi-location demand reasoning is not in scope of the BC-native extension; it is back-of-spreadsheet work.

Sparse, volatile, and new items get filtered out

The Azure AI engine underneath the Sales and Inventory Forecast extension requires a minimum of five historical periods of demand data, and applies a configurable Variance Tolerance threshold (default ~20%, tunable per tenant) that filters out forecasts the engine cannot produce with confidence. [3] The behavior is sensible engineering — don’t return a number you can’t stand behind — but the operational consequence is that BC’s long tail (slow-movers, recently-launched items, seasonal-spike SKUs) returns no forecast. Exactly the inventory the planner most needs help with.

The operator framing is blunter than the docs. An r/Dynamics365 planner in 2026: “forecasts and MRP look fine on paper, but once volatility kicks in, inventory reality starts to drift pretty quickly.” [5] A 2026 r/supplychain demand planner: “it does a good job at statistical forecasting, but not [useful] for consensus demand planning.” [6]

No promo or seasonal-event awareness

BC’s Demand Forecast Entry table does not understand that a Black Friday spike will pull demand forward and depress demand for the following two weeks. There is no planner-facing promo calendar inside BC, and the forecast extension does not detect promo periods from the sales pattern. Planners maintain promo and seasonal-event calendars in Excel — feeding stat #4 from this page’s hero block: 67.4% Excel reliance among supply-chain managers. [7]

The incumbent BC-native forecasting add-on, Insight Works’ Enhanced Forecasting Worksheet, is candid about the boundary. Their own engineering blog calls BC’s built-in forecast “a starting point but not a planning tool” and enumerates five specific gaps — none of which their tool fully closes either. [8]

What Isovel adds — ensemble ML and confidence bands

Isovel runs an ensemble of machine-learning forecasters (Darts, statsforecast, and a Prophet-class baseline) across SKU-location time series and returns a forecast with a confidence band and a rationale string for every line. The ensemble approach matters because no single algorithm wins across every SKU pattern — short-history items, intermittent demand, and steady-state high-velocity SKUs all benefit from different models. The mix is tuned per-SKU as the agent learns from your actual demand against its own back-cast.

Crucially, the agent never returns a “cannot forecast” wall. Short-history SKUs, slow-movers, and new items still get a confidence-banded estimate with the reasoning attached — “forecasted from category baseline; expand history before relying on it,” for example. That graceful-degradation behavior is the single biggest gap in BC’s native forecasting, where Azure AI’s five-period minimum and variance threshold exclude exactly the items planners most need help with.

The forecast itself is necessary but not sufficient. The closed-loop work — feeding the forecast into the Planning Worksheet, distributing across locations, weighing MOQs, deciding what to order — is what Isovel was built for.

Promo and seasonality, auto-detected

Most demand-planning tools either ignore promos and seasonality or ask the planner to maintain a manual calendar — which violates the zero-setup wedge and is exactly what BC planners are already doing in Excel. Isovel works in two passes. Historical promo detection: the agent identifies promo and seasonal-event periods in your past sales data by detecting anomalies against the SKU’s baseline pattern, then learns the lift-and-trough shape so the forecast accounts for it the next time a similar period appears. Forward-looking promo flagging: a planner can flag a known upcoming launch, pricing change, or event in one click; the agent then applies the learned shape to that window. Per-SKU and per-category granularity, no calendar to maintain. Isovel does not claim to predict unannounced promotions — that is not what anomaly detection does.

The Excel calendar is gone, and with it a meaningful chunk of the spreadsheet-error tax: industry aggregator data lands around 90% of spreadsheets containing errors. [9]

Multi-location demand reasoning

MVP Tier 0

Isovel forecasts demand per location, not aggregate-then-distribute. The agent reads BC’s location master, the existing item-location relationships, and the sales-history per location, and produces a location-aware forecast that respects local demand patterns and seasonal differences between warehouses.

The realistic edge case for BC mid-market distribution is thin per-location history on B/C-velocity SKUs — a location with only a handful of recent orders for a slow-mover. Isovel handles this with a hierarchical fallback: the item-total forecast is disaggregated to the location using the location’s recent share of total demand as the prior, and the rationale string makes the fallback explicit (“per-location forecast from item-total disaggregated by 14-week location share; expand local history to refine”). The planner sees what the agent did and why.

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 per-location forecast turns into transfer-order recommendations alongside purchase-order recommendations — see /multi-location-inventory-rebalancing/ and /for-business-central/replenishment/.

Connects via Microsoft’s own external-engine entry point

The install does not require disabling BC or migrating data. Isovel connects to your BC tenant via Office 365 SSO and registers itself as the external forecasting engine through the same Sales and Inventory Forecast Setup that Microsoft documents. [3] [4]

Once connected, Isovel pulls sales orders, sales quotes, item ledger entries, locations, vendors, and lead-time history. It populates the Demand Forecast Entry table that BC’s Planning Worksheet already reads — so the rest of your BC tenant continues to work exactly as it did. The agent writes forecasts in an idempotent, approval-gated, and reversible pattern: re-running a forecast generation never duplicates entries, every write-back is logged in the audit trail, and any action is reversible within a 24-hour rollback window. This is structurally important — the underlying BC table is not idempotent at the platform layer (a 2026 r/Dynamics365 thread documented that “importing a Demand Forecast with RapidStart creates duplicate entries” [11] ), so the calling engine has to enforce idempotency. Isovel’s write-back layer does.

No consultant. No migration. No forecast hierarchy to maintain.

How accuracy is measured (and what we publish)

Per Isovel’s standing non-negotiable: we publish our own forecast-accuracy benchmarks, and we do not cite competitor accuracy headline numbers. The methodology, public on this page from day one:

  • Test set definition — per-customer holdouts using the trailing 13 weeks of actual demand as a withheld evaluation set (separate from the 13-week forward horizon Isovel forecasts). Training on demand prior to the holdout; evaluating against the holdout’s actuals. Separate evaluation buckets for high-velocity (A-class), mid-velocity (B-class), slow-mover (C-class), and new-item (no-history) SKUs.
  • Accuracy metric — symmetric MAPE (sMAPE) at the SKU-location-week granularity, with weighted variants for high-revenue SKUs reported alongside.
  • Comparison baseline — Isovel vs. BC native (the Sales and Inventory Forecast extension) on the same SKU-location-week holdout. No external aggregator benchmarks cited as accuracy comparisons; the customer’s own BC tenant is the only honest baseline.
  • Cadence — first published benchmark at general availability; updated quarterly thereafter; methodology stable.

The point of this section being on the page before benchmark numbers exist is to commit to the discipline. A 10-year demand planner on r/supplychain in 2026 was blunt about category-wide accuracy claims: “in over two years we never received a demand planning software that was over 50% accurate when compared with actual.” [12] The right answer is to publish real numbers, not marketing numbers. Until our first benchmark lands, treat any vendor-stated headline accuracy claim with skepticism — including ours-to-be.

Replaces the Enhanced Forecasting Worksheet

The Enhanced Forecasting Worksheet from Insight Works is the most-installed BC-native forecasting add-on. EFW improves the display layer on top of BC’s built-in forecast surface. It does not switch the underlying engine away from Azure AI, does not add multi-location distribution, does not auto-detect promos, and does not write replenishment decisions back to BC.

The same architectural pattern holds for the other AppSource BC forecasting solutions ChatGPT currently names — Adroit Forecaster, Lanham Demand Planning, Naviona Demand Forecasting: each adds a display surface or a specialized algorithm on top of BC’s planning surface, but none of them replaces the forecast engine via the external-engine entry point and writes a closed-loop decision back into the Requisition Worksheet. Isovel is the engine-replacement and decision-layer category, not the display-improvement category.

Coexistence is not the design point. Both EFW and Isovel write to the same Demand Forecast Entry table, which would create predictable write conflicts. Isovel replaces EFW; it does not stack on top of it. Onboarding detects EFW and walks you through disabling it before write-back is enabled.

The head-to-head — engine architecture, multi-location, promo handling, write-back posture, migration path — lives at /alternatives/enhanced-forecasting-worksheet/.

Business Central demand-forecasting FAQ

1. Does Isovel replace the Sales and Inventory Forecast extension in BC? Yes. Isovel registers as the external forecast engine via the Sales and Inventory Forecast Setup’s external-engine entry point. [4] The BC forecast page and Planning Worksheet continue to read from the Demand Forecast Entry table; Isovel populates that table. Running both the Azure AI engine and Isovel against the same tenant is not supported — they would compete for the same Demand Forecast entries.

2. Does Isovel work alongside Microsoft Copilot for Business Central? Yes. Microsoft’s own May 2026 Copilot for Business Central FAQ states forecasting features “aren’t related to Copilot.” [13] The two products do different work and do not overlap. Copilot narrates BC data and accelerates in-system tasks; Isovel forecasts demand, decides replenishment, and writes draft purchase orders and transfer orders back into BC.

3. How does Isovel handle new items with no sales history? Confidence-banded baseline forecast with rationale string (“forecasted from category baseline; expand history before relying on it”). Never a refusal. Compare: Azure AI in BC requires at least five historical periods and refuses above its documented variance threshold. [3]

4. How does Isovel handle promotions and seasonality without a calendar? Anomaly detection on baseline sales patterns plus a return-to-baseline window after the promo closes. Per-SKU and per-category granularity. Optional manual override for known upcoming promotions. No planner-maintained calendar — that preserves the zero-setup wedge.

5. What forecast horizon does Isovel cover? 13-week rolling horizon out of the box, with weekly buckets — the typical cadence for BC mid-market planners. Horizon is configurable per tenant; longer horizons are available for capacity and S&OP-style work as that feature surface lands in Phase 2.

6. Does Isovel forecast at the location level? Yes — per location, not aggregate-then-distribute. BC’s built-in extension produces aggregated forecasts and asks the planner to distribute by hand. [3] Isovel reads the location master, sales-history per location, and existing item-location relationships, and produces a location-aware forecast.

7. How is forecast accuracy measured? Per-customer holdouts using the last 13 weeks of demand. Symmetric MAPE at SKU-location-week granularity, separately reported by SKU velocity class (A/B/C) and new-item bucket. Comparison baseline includes BC native and the industry MAPE benchmark. First public benchmark publishes at general availability; cadence is quarterly thereafter.

8. Which versions of Business Central does this work with? Business Central 25, 24, and 23. Cloud and on-premises. Connector authenticates via Office 365 SSO and uses BC’s documented OData and Web Services surfaces plus the Sales and Inventory Forecast Setup external-engine entry point.

See the forecast on your own BC tenant. Get early access →

Forecast engine shaped by what BC operators actually do every Monday

The forecast-engine architecture in Isovel was shaped by the work BC mid-market distributors actually do every Monday morning — distributing an aggregated forecast across locations by hand, opening Excel for the long-tail items Azure AI excludes, maintaining a parallel promo calendar nobody else can see. Every behavior the agent ships — per-location forecasting in a single pass, graceful degradation on slow-movers and new items, automatic promo and seasonal detection, idempotent write-back to BC’s Demand Forecast Entry table — closes a gap real BC planners are working around today.