AI Time Series Forecasting for FP&A Teams — deFacto Foresight

How dF Foresight works in deFacto

A planner sets the time range, the scenario to forecast, a destination label, horizon, frequency, and training scenario, then runs dF Foresight from the Excel add-in or the dF Modeler visual in Power BI. The forecast — predicted values, confidence intervals, and any exogenous driver series — writes directly into the chosen deFacto scenario. That scenario is now part of the plan: the same model used for budget, actuals, and variance. No export step, no copy-paste, no reconciled spreadsheet.

The forecast model is Nixtla TimeGPT-2.1

The production and demo forecast model is Nixtla TimeGPT-2.1. The TimeGPT-2 family ranks top-3 on GIFT-Eval, FEV, and VN1 — three standard forecasting benchmarks — with up to 60% improvement over the prior generation. In practice, results depend on data quality, horizon, and whether exogenous drivers are included; the benchmark establishes the quality floor of the underlying model. For Azure deployments, dF Foresight runs TimeGPT-2 (Azure edition) — a distinct binary from the direct Nixtla TimeGPT-2.1 path. For teams with data residency or compliance requirements that prevent sending financial data to a public API, the sovereign AI path runs Google TimesFM 2.5 locally on the customer’s own infrastructure. TimesFM is also available as an algorithm within Anaplan Forecaster Advanced (cloud-hosted); deFacto’s differentiator is the sovereign path — TimesFM running on the customer’s own infrastructure — combined with Excel and Power BI write-back into a named planning scenario.

Exogenous drivers make the forecast non-univariate

Optional exogenous variables — for example UnitPrice and UnitCost from the deFacto fact table — drive the forecast alongside historical volume, including planned future driver values. A revenue forecast that incorporates planned price changes or known cost movements is more useful than one that extrapolates volume alone. The exogenous driver series come from the same deFacto model the planner works in, so there is no separate data preparation step. Fast backtesting over prior actuals lets the team validate absolute percentage error against their specific data before committing to a horizon.

How to evaluate time-series forecasting in a planning platform

Not all forecasting tools answer the same question for FP&A teams. These are the criteria that separate solutions that work in practice from ones that work in a demo.

1. Does the forecast write back into the planning model?

A forecast that lands in a connected planning scenario is immediately comparable against budget and actuals. A forecast that lives in a separate analytics tool requires a manual reconciliation step before any finance team member can act on it. For planning teams, write-back is the difference between a forecast that becomes the plan and one that becomes a slide.

2. Can the forecast incorporate business drivers?

Univariate forecasting extrapolates historical volume. Non-univariate forecasting accounts for known changes in the operating environment — price moves, volume shifts, planned events — by including exogenous driver variables. For FP&A teams where revenue is driven by price and volume separately, univariate forecasting produces a number that finance cannot defend.

3. What is the underlying model, and what does the benchmark mean for your data?

Model benchmarks (GIFT-Eval, FEV, VN1) establish relative quality across broad evaluation sets. They are directionally useful but are not the same as a backtest on your specific data, frequency, and horizon. A fast backtest over your own prior actuals gives a more reliable read on accuracy than benchmark ranks alone.

4. Does the solution run where your data is allowed to go?

Some finance teams cannot send financial time series to a public API for compliance, data residency, or policy reasons. An on-premises or private-cloud forecasting option matters for those organisations — it should be available from the same planning environment, not a separate deployment.

Forecasting platform comparison

Source: BPM Partners Vendor Landscape Matrix and Budgeting and Planning Buyers Guide, July 2025.

What dF Foresight is not for

dF Foresight is built for finance planning cadences — monthly, weekly, and daily series with planning-relevant horizons. It is not designed for real-time streaming forecasting, high-frequency signal processing, or supply chain network optimisation at the SKU-location level. For teams with fewer than 12 months of actuals, the confidence bands will be wider and results less reliable; the deFacto team will advise on data minimums for a specific cadence during a scoping conversation. For supply chain optimisation problems at network scale, platforms such as Kinaxis and SAP IBP are designed for that use case — dF Foresight is the forecasting layer within the Finance Planning System of Record, not a supply chain solver.

dF Foresight and teams that want to bring their own model

Finance teams with an in-house data science function sometimes want to use a proprietary or internally trained model rather than a standard foundation model. dF Foresight supports this. The write-back layer and the forecast engine are architecturally separate — the integration into the deFacto planning model does not change when the forecast engine changes.

Note that the Azure path for dF Foresight uses TimeGPT-2 (Azure edition), a distinct Nixtla binary hosted in your Azure subscription — this is separate from bringing a fully custom model via Azure Machine Learning. For teams that want to deploy a custom model, deFacto works with you on two paths:

Nixtla NeuralForecast: For teams that want full control over model architecture and training on their own financial time series, NeuralForecast provides a production-grade open-source framework — NBEATS, NHITS, TFT, and others — that integrates with the dF Foresight write-back layer. Your model, your training data, deFacto’s planning integration.

Azure Machine Learning: For teams already operating on Azure infrastructure, dF Foresight can route the forecast call through an Azure ML-deployed model endpoint — a custom or fine-tuned model hosted in your own Azure subscription — and write the result into the connected deFacto scenario. This keeps the model, the data, and the compute within your existing Azure governance boundary.

Both paths preserve the core dF Foresight behaviour: the forecast writes into the plan, not into a separate output file requiring manual reconciliation.

Where dF Foresight fits in the deFacto AI model

dF Foresight is one of four AI capabilities on the deFacto platform. The others — dF Anomaly, dF Notify, and conversational agents — run on the same connected deFacto model. Anomaly detection and forecasting share the same TimeGPT-2.1 engine, which means both produce auditable, consistent model behaviour — not two separate black boxes. For deployments requiring a locally hosted forecast model, the sovereign AI path routes to Google TimesFM 2.5 on customer infrastructure.