Demand Forecasting in Dynamics 365 Supply Chain: Why AI Predictions Still Need a Finance Controller

Supply chain analytics dashboard showing demand forecasting data

Your supply chain forecasting process relies on a spreadsheet, email chains, and quarterly consensus meetings where people argue about whether next quarter looks “up” or “down.” By the time everyone agrees, demand has already shifted. Dynamics 365 Supply Chain includes native demand forecasting powered by machine learning, and it looks compelling: automatic pattern detection, seasonal adjustment, and predictions backed by months of transaction history. The promise is clear: let the algorithm handle it, and inventory optimizes itself.

But here’s what most supply chain leaders discover after three months of production use: the algorithm is confident and occasionally wrong in expensive ways. A Dynamics 365 demand forecast can show 10% growth next quarter because of a single promotion cycle two years ago that now looks like a trend. Or it can predict stable demand when a major customer just went silent. The numbers are rigorous; the business context is not.

This is not a Dynamics 365 limitation, but a forecasting reality that CFOs and supply chain directors need to understand before they flip the switch on full automation. The technology works. The question is how to use it without letting the model’s confidence substitute for financial discipline.

Supply chain planning dashboard with demand forecasting metrics

What Dynamics 365 Demand Forecasting Actually Predicts

Dynamics 365 Supply Chain uses machine learning to analyze historical demand patterns and generate point forecasts for future periods, typically one to twelve months out. The system takes transaction history (sales orders, purchase orders, inventory movements), identifies seasonality, trend, and cyclical patterns, and applies time-series decomposition to produce a predicted demand volume for each item in each period.

The key phrase is “point forecast”: a single number per period per item, not a range. It’s precise, quantifiable, and immediately actionable as a target for production planning, procurement, and inventory targets. The model uses techniques like exponential smoothing and ARIMA (AutoRegressive Integrated Moving Average) to weight recent history more heavily and adjust for seasonal swings observed over multiple years.

For many product categories, this works well. If you sell a consistent product with stable customer base and predictable seasonality, a machine learning forecast often beats manual judgment. The algorithm isn’t emotional, doesn’t anchor to last year’s number, and picks up subtle patterns that a spreadsheet jockey might miss. This is not theoretical; it’s production reality across hundreds of implementations.

The Finance Controller’s Problem with Pure Automation

The trouble arrives when the model’s assumptions break down. Here are three scenarios that appear in almost every supply chain forecasting implementation:

Scenario 1: A Large Customer Goes Quiet or Leaves. Your top customer, representing 22% of annual demand for a product family, doesn’t place an order for two periods. The demand forecast model has five years of history showing this customer as rock-solid steady, so the algorithm predicts normal consumption in period three, waiting for the order that never comes. A human supply chain planner would escalate the issue to sales or customer success immediately. A finance controller would note the drop in the forecast, not wait for the model to recalibrate across six more months of zero orders.

Scenario 2: One-Time Promotions Create False Trends. Last summer, you ran a promotional campaign that drove a 40% spike in demand for a specific product. The machine learning model, looking at the last 24 months of history, detects this spike and attributes a portion of it to an underlying trend shift rather than recognizing it as a one-time event. The forecast for next summer incorporates this “trend,” predicting sustained 20% elevation even though you have no plans to run the promotion again. A finance controller reviewing the forecast would flag this immediately (“Did we plan a promotion? No.”). The algorithm does not ask strategic questions.

Scenario 3: Timing Mismatch Between Demand Signal and Forecast Recalculation. You learn on Tuesday that a major product line is being discontinued. The demand forecast in Dynamics 365, calculated on last Friday, still predicts normal consumption through quarter-end. The model will not be recalculated until next Friday’s batch run. By the time the new forecast is available, you’ve already committed to purchase commitments and production schedules based on outdated data. A finance controller who is manually involved in forecast validation can adjust the prediction immediately.

In each of these scenarios, the machine learning model is not “wrong” in statistical terms. It’s following its design: predict based on historical patterns. The business context (personnel changes, campaign decisions, strategic shifts) happens faster than the model’s training cycle can absorb. Finance leaders know this. Supply chain leaders know this. But when the system is fully automated, nobody is asking the question.

The Dynamics 365 Approach: Automation With Financial Governance

Dynamics 365 Supply Chain’s forecasting engine does include governance features, but they work best when treated as mandatory checkpoints, not optional. The system allows you to:

Set override rules at the item or item-family level, specifying factors by which the model’s predictions should be adjusted (for example, “multiply this item’s forecast by 1.15 for next quarter because we’re running a promotion”). You can also set absolute override values, replacing the model’s prediction entirely for specific items in specific periods.

Use Demand Forecast Accuracy KPIs to measure how well the model’s past predictions match actual demand, broken down by item family and customer segment. If a forecast consistently misses by 15% for a certain category, that’s a signal to investigate whether the model’s assumptions are still valid or whether market conditions have shifted in ways the historical data doesn’t capture.

Manually adjust forecasts before they feed into production planning by creating a Demand Forecast Adjustments form, where supply chain planners and finance controllers can document specific business reasons for adjusting (or accepting) each model-generated prediction. This creates an audit trail: months later, you can see that Q2 forecasts were intentionally lifted 8% because of an announced customer expansion, distinguishing intentional adjustments from modeling error.

Integrate the demand forecast into a Dynamics 365 Planning Optimization run, which also accounts for supply constraints, lead times, and safety stock levels. The forecast is just one input; planning optimization adjusts based on the full supply picture.

None of these features bypass the algorithm. They layer financial and business governance on top of the automation, recognizing that pure model-driven forecasting works until it doesn’t, and having a second set of eyes looking at the numbers before they lock in procurement and production schedules saves more money than pure automation typically gains.

The Finance-Supply Chain Handoff: How the Best Teams Use Forecasting

Organizations that get strong results from Dynamics 365 demand forecasting typically follow a pattern:

Supply chain operations generates the base forecast using the machine learning model and treats it as a starting point, not a decision. They run the model on a fixed schedule (for example, every Friday afternoon) and document any configuration changes (for example, a customer’s demand type changes from baseline to promotional).

Demand planning, working with sales and marketing, reviews the forecast against known business events: major customer wins or losses, planned promotions, supply disruptions, or strategic inventory adjustments. They create documented adjustments in the system, so the model is informed of one-time events versus trends.

Finance and the controller function reviews the resulting forecast for cash flow, working capital, and procurement commitment implications before it locks in. A 30% demand lift for a product with a 90-day supply lead time means purchasing commitments, warehouse space, and cash flow assumptions need to shift accordingly. The finance controller’s approval step is the gate between “the model predicts” and “we’re committed to this plan.”

Production planning and procurement teams execute on the approved forecast, knowing it has been vetted by both demand planning and finance.

The entire cycle takes three to five days, depending on forecast complexity and business complexity. It’s not fully automated, but it’s not a spreadsheet-and-email process either. The machine learning model handles the analytical heavy lifting; human judgment handles the business context.

Getting Started Without Overhauling Your Current Process

If your organization currently uses manual forecasting or legacy forecasting tools, migrating to Dynamics 365 demand forecasting does not require overhaul on day one.

Start by running the Dynamics 365 forecast in parallel with your current process for one full planning cycle. Load several months of historical demand data into Dynamics 365 Supply Chain, configure the forecasting parameters (for example, seasonality windows, forecast time horizon), and let the model generate predictions. Compare the Dynamics 365 forecast to the forecast you would have created manually. Where do they agree? Where do they diverge, and why?

This parallel run gives you three things: validation that the model is picking up your business’s actual patterns, a baseline for measuring the model’s accuracy going forward, and team confidence that the system understands your supply picture before you make it a dependency.

Once you’re confident in the model’s direction, layer in governance. Designate a demand planning role in Dynamics 365 and grant that person permission to create forecast adjustments. Set up a simple adjustment log: which items are adjusted, by how much, and the business reason. Don’t try to perfect the process; just capture the decision.

Then pilot the forecast-to-planning integration with a subset of your highest-value items or customer segments. Run planning optimization using the Dynamics 365 forecast and compare the resulting purchase orders and production schedules to what you’re currently doing. If the plan improves (lower safety stock, fewer expedited orders, better cash flow alignment), expand the scope. If it diverges significantly from reality, investigate whether the forecast or the planning parameters need adjustment.

This three-step approach keeps risk contained while building organizational confidence that demand forecasting automation is working for you, not against you.

Conclusion

Demand forecasting in Dynamics 365 Supply Chain is a powerful tool for reducing guesswork and improving inventory efficiency. But “powerful” is not the same as “fully autonomous.” The best implementations treat the machine learning model as a rigorous analyst that handles pattern recognition at scale, paired with finance and supply chain leadership who understand the business context that no model can capture.

If your organization is evaluating demand forecasting or has already deployed it, the question is not whether to use the algorithm. It’s how to build a governance process that keeps human judgment and financial discipline in the loop without slowing your planning cycle to a crawl. Dynamics 365 makes that possible, as long as finance leaders and supply chain teams treat the forecast as input to a decision, not a decision itself.

Routeget Technologies brings enterprise Dynamics 365 implementation and optimization expertise to organizations across finance, supply chain, and customer engagement. Our consultants work with supply chain teams and finance leaders to design forecasting governance that balances automation with financial control, reducing inventory costs while improving forecast accuracy and auditability.

#DemandForecasting #DynamicsSupplyChain #InventoryOptimization #SupplyChainPlanning #FinanceAutomation #DynamicsERP #SCMStrategy

Project Profitability in Dynamics 365 Project Operations: Why Your Project Margins Fail Without Proper Accounting Setup

Dynamics 365 Project Operations financial dashboard showing project profitability metrics

A professional services firm running Dynamics 365 Project Operations pulls its monthly margin report and finds something that doesn’t match reality on the ground. One fixed-price engagement shows a 60 percent margin despite the delivery team saying they’ve been slammed for weeks. Another time-and-materials project shows a loss even though every hour logged was billed. Nobody misused the system. Nobody entered a wrong number. The transactions are all correct, and the margins are still wrong, because project profitability in Dynamics 365 Project Operations is decided by the accounting setup behind those transactions, not by the transactions themselves.

Dynamics 365 Project Operations financial dashboard showing project profitability metrics

Two Price Lists, One Easy Mix-Up

Project Operations resolves cost and revenue through separate price lists, and the distinction matters more than the name suggests. A cost price list resolves the rates used on cost-type estimate and actual transactions, essentially what a resource actually costs the business. A sales price list resolves the rates used on the billed and unbilled sales side, essentially what gets charged to the customer. Each is set to a context, Cost or Sales, and that context governs how the system looks the record up. Set a list to the wrong context and price resolution simply fails to find a rate where one should exist.

Sales price lists carry another constraint cost lists don’t: they’re locked to the currency defined on the list header, while cost price lists can hold role prices in other currencies through user setup overrides. That asymmetry catches multinational firms more often than it should, particularly when a role price gets added to a sales list in the wrong currency and the transaction silently falls back to a default rate instead of erroring out. Sales price lists also have to be explicitly attached, to a customer’s project price list, a project quote, or a project contract, before they apply to anything; a rate sitting correctly configured but never attached to the contract in play won’t be used. Add date ranges into the mix, since price lists apply based on start and end dates, and a gap between two lists means a stretch of transactions with no applicable rate at all.

Where Margin Actually Gets Decided

Price lists set the numbers going into a transaction. What happens to those numbers on the ledger, which is what actually produces a margin figure, is governed by a separate configuration object: the project cost and revenue profile, found under Project management and accounting, Setup, Posting. This is the part of the setup that gets underinvested in relative to how much leverage it has over reported profitability.

The ledger settings on a profile decide, transaction type by transaction type, hour, expense, item, whether costs post straight to the profit and loss statement or sit on the balance sheet as work in progress until someone runs a separate posting step. They also decide whether on-account, milestone-based invoicing lands in a balance account or a P&L account, and whether unbilled revenue gets accrued to the general ledger at all. None of these settings are visible on the transaction itself. A time entry looks identical whether its hours are configured to post immediately or to wait in WIP, which is exactly why a wrong setting here doesn’t throw an error. It just quietly changes what shows up as margin.

Finance professional reviewing project accounting and cost allocation data

Fixed-Price Work Needs Its Own Logic

Time-and-materials projects recognize revenue roughly as work happens, so the profile settings above cover most of what matters. Fixed-price projects need an additional layer, because the billing schedule and the actual delivery pace are two different things, and the whole point of the accounting setup is to keep them from contaminating each other. Project Operations offers three methods here. Completed contract holds all revenue and cost recognition until the project finishes, carrying everything as WIP in the meantime. Completed percentage accrues revenue periodically based on how much of the project is actually done, using cost templates to group transactions for the percentage-complete calculation and period codes to set how often that calculation runs. No WIP skips the deferral entirely and is meant for short engagements where invoicing and cost recognition happen close enough together that deferral adds nothing but complexity.

A firm running long, milestone-heavy fixed-price engagements under a “no WIP” setup, because that was the default nobody revisited, will see revenue and cost recognized in whatever period the invoice happens to fall in rather than the period the work actually happened in. Margins swing from project to project not because delivery efficiency is inconsistent, but because the accounting method assumes short-cycle work being applied to long-cycle contracts.

Five Specific Ways This Goes Wrong

A handful of misconfiguration patterns show up repeatedly enough to be worth naming directly. A billing method mismatch, where time is set to fixed-price logic on what’s actually a time-and-materials engagement, or the reverse, throws off exactly when hours or expenses hit revenue relative to when they’re billed. A missed manual step is just as damaging: when hour or expense costs are set to post to a balance account rather than profit and loss, someone has to run the “post costs” function to move them into P&L, and if that step is skipped, costs simply never show up against revenue, producing a margin that looks better than it is. A mismatched revenue recognition method does similar damage from the other direction, completed contract selected on the profile while revenue is somehow still being accrued on a monthly cadence, which mismatches costs and revenue by period and makes margins swing without any real change in delivery.

The accrual settings create a subtler trap. Revenue accrual turned on for a time-and-materials engagement whose cost posting is set to “no ledger” produces transactions where revenue is recognized but the matching cost is never posted anywhere, which can show as a margin approaching 100 percent on paper. And on-account invoicing routed to a profit and loss account instead of a balance account recognizes milestone billings as revenue immediately, ahead of the delivery they’re meant to represent, front-loading margin into whichever period the invoice happens to land in.

Getting Project Profitability Right Before the Numbers Matter

None of this is complicated once it’s named, but it has to be checked deliberately rather than assumed. Start by confirming which billing method, time-and-materials or fixed-price, is actually assigned to each active profile, and cross-check that against how the contracts using that profile are actually structured. Walk the ledger settings for each transaction type and confirm someone owns the recurring job of running the “post costs” function if any type is set to balance posting, since that step doesn’t run itself. For fixed-price work, match the recognition method to the actual shape of the engagement rather than the platform default, short and simple work can reasonably use no WIP, but anything spanning multiple billing cycles needs completed percentage with cost templates that actually reflect how the project’s cost mix is structured. Finally, verify that profile assignment rules, by contract, project group, or individual project, are actually routing each engagement to the profile that matches how it’s billed, since a firm running several contract types often has profiles that were configured correctly once and then silently misapplied as the portfolio grew.

Routeget Technologies has walked in behind project-based businesses whose delivery teams were being blamed for margin problems that turned out to live entirely in the posting configuration, not the work. Reconciling that gap usually takes a focused audit of the profile settings against a sample of actual contracts, not a re-implementation, and it tends to be one of the highest-leverage half-days a Project Operations environment can spend.

#ProjectProfitability #ProjectAccounting #ProjectOperations #RevenueRecognition #WIPAccounting #CFOStrategy