Yes. FP&A (financial planning and analysis) software can forecast from operational drivers such as bookings, visits or units, while using general ledger (GL) actuals to calibrate assumptions and reconcile results. Connecting operational systems lets finance model how expected activity affects revenue and costs. Driver-based forecasting makes those assumptions explicit; the ledger still provides the financial baseline.
What makes a forecast driver-based rather than historical?
A driver-based forecast calculates each line from the business activity that causes it. Revenue equals units times price, or customers times average revenue. A historical forecast takes GL trends and extends them, usually by growth rate or a trailing average.
Consider an illustrative software company whose forecast extends recent revenue growth. Two customers give notice in April that their subscriptions will end on June 30. A driver model can update the forecast immediately, with churn affecting the recurring base from July. Recognized revenue follows the service and recognition schedules. A trend-based forecast can also reflect the change if finance adjusts its assumptions.
Drivers also make a forecast explainable. When the CFO asks why next quarter’s revenue fell, a driver model answers in business terms: fewer bookings, higher churn, a pricing change. A trend model needs additional operational analysis to explain the change.
Not every line needs a driver. Rent, insurance and most software subscriptions are better forecast from contracts or schedules. Small, stable lines can follow history. Spend driver effort where most of the variance comes from, usually revenue, headcount and cost of revenue.
For each forecast line, name the input that would change it and explain the relationship. If that link cannot be explained, document and test the assumption before relying on it.
Where do operational driver inputs come from?
Operational driver inputs come from the systems that record the activity:
- Customer relationship management (CRM): pipeline and bookings.
- Billing systems: subscriptions.
- Scheduling systems: visits.
- Point-of-sale (POS) systems: units sold.
- Human resources information systems (HRIS): headcount.
Each driver needs a defined source, an owner and a refresh schedule.
Operational inputs can stay current while prior forecasts remain reproducible. At each forecast cutoff, preserve the source-data snapshot, assumptions, model version and output used for that forecast. Continue refreshing a separate working forecast, then explain changes against the saved baseline. A fixed monthly snapshot is one option; the cadence should match the decision.
Align driver definitions before connecting data. For example, if revenue operations counts qualified pipeline from stage two but finance applies a conversion rate measured from stage three, the forecast mixes different populations. Match the conversion rate’s denominator to the pipeline stage and time period being forecast.
Map operational data to finance dimensions. Products in the CRM should match product lines in the P&L, clinics in the scheduling system should match ledger locations, and stores in the POS system should match cost centers. Without that mapping, drivers sit beside the financial model instead of inside it.
Keep a driver register, like a chart of accounts for operational assumptions, with:
- Definition, unit of measure and calculation.
- Source system and mapping to finance dimensions.
- Owner, refresh schedule and forecast cutoff.
- Assumptions and version used for each forecast.
Can I model ARR, MRR and other SaaS metrics?
Yes. FP&A software can forecast annual recurring revenue (ARR) and monthly recurring revenue (MRR) from an opening recurring-revenue base plus new subscriptions and expansion, less contraction and churn. These recurring-revenue metrics measure the subscription run rate. Build the P&L revenue forecast separately from the underlying service periods and revenue-recognition schedules.
This illustrative Q3 ARR waterfall tracks annualized recurring revenue, not revenue earned during Q3:
| ARR movement | Q3 amount |
|---|---|
| Beginning ARR | $12.00M |
| New customers | $1.10M |
| Expansion | $0.40M |
| Contraction | ($0.15M) |
| Churn | ($0.35M) |
| Ending ARR | $13.00M |
Using a consistent ARR = 12 × MRR definition, ending MRR is about $1.08 million. Opening-cohort net revenue retention (NRR) is (12.00 + 0.40 – 0.15 – 0.35) ÷ 12.00 = 99.17%, provided those movements all relate to customers present at the start of Q3. New-customer ARR is excluded.
Write down the ARR and MRR definitions before comparing periods: which subscriptions qualify, when they enter or leave the metric, and how usage and currency changes are treated. For example, Stripe publishes its own MRR inclusion rules.
Reconcile recurring-revenue metrics to the ledger through an explicit bridge. Align the customer scope and currency, then explain differences between the recurring-revenue snapshot and the period’s recognized revenue, including service dates, usage, one-time items and recognition timing. Investigate unexplained changes against the agreed metric definition and recognition schedule.
How do I model sector-specific drivers like physician volumes and payer mix?
Build revenue from the operational units of the sector, then apply the rates that turn units into money. In healthcare, that means providers, visits per provider, working days and reimbursement by payer. In logistics, it is shipments and revenue per shipment. In services, billable hours and rates.
This illustrative healthcare scenario shows the structure. A clinic group with 14 physicians, each seeing 18 patients a day over 20 working days, expects 5,040 visits a month. Revenue depends on payer mix: Medicare, Medicaid, commercial insurance and self-pay each reimburse differently. If Medicare’s share of visits rises from 38 to 42 percent and commercial falls by the same amount, average reimbursement per visit drops even though volume is flat.
Medicare rates come from the Physician Fee Schedule that the Centers for Medicare & Medicaid Services publishes each year (CMS, 2026). Commercial rates come from contracts. Both belong in a rate table the model reads, updated when rates change.
Datarails FP&A supports driver-based models in Excel and Google Sheets, with FinanceOS® as the governed foundation connecting financial and operational data. Refreshable formulas and tables bring mapped inputs into the model. For a visits-based forecast, confirm that scheduling and billing connections expose the required fields, then align visits, collections and ledger data by entity and period.
Track the driver variances each month: volume, mix and rate. They explain revenue in the terms operators use.
Can I plan at SKU or daily level?
SKU or daily planning is useful where that detail changes decisions. For example, 3,000 SKUs over 365 days creates 1,095,000 values per line before adding stores or scenarios. One practical approach is to plan the top items at SKU level and the long tail by category.
The split usually follows sales concentration. If 200 SKUs produce most of revenue, plan them individually by month or week, and plan the remaining items at category level with a mix assumption. Review the split each year, because new products move into the top group.
Daily planning suits businesses where days differ sharply, such as restaurants, retail and hospitality. A restaurant group might plan covers by day of week, because Friday and Tuesday bear little resemblance. Monthly totals then roll up from daily plans.
Granularity has a cost in review time. A plan nobody can review at the level it is built becomes a plan nobody trusts. Keep detail where someone will act on it.
Datarails can bring detailed actuals from supported POS and ERP (enterprise resource planning) connections into FinanceOS when the required fields are available and mapped. In supported reports, users can drill into the records contributing to a value. A category-level forecast has SKU or daily detail only if the model includes it; detailed actuals alone do not create a matching forecast breakdown.
How do I build promotional planning into a forecast?
Model each promotion with its expected lift, the discount cost, and the effects before and after it: pull-forward, cannibalization and any halo on other products. A promotion that adds volume during the event and removes it afterward should not appear as pure growth.
Consider this illustrative promotion scenario. A retailer runs a 20 percent discount on a product line for two weeks. Expected unit lift is 35 percent during the promotion. Sales in the following two weeks typically fall about 10 percent below baseline, because customers bought early. Net units over four weeks rise far less than the headline lift, and margin falls because of the discount.
Store promotions as a calendar with attributes: dates, products, discount, channel and expected lift. The forecast reads the calendar and applies the effects, so promotions can be added or moved without editing formulas.
After each promotion, compare results with a baseline that accounts for seasonality, availability and other campaigns. Separate sales brought forward from additional demand, then revise assumptions where the evidence supports it.
Promotions also affect cash and inventory. Plan the inventory build ahead of the event, and expect lower average prices in collections. The guide to AI for forecasting and scenario analysis explains how connected data supports scenario testing.
Start with two operational drivers
Pick your largest revenue line and name the two operational inputs that move it most. Build a driver register for those two first. In a Datarails demo, ask to trace one driver from its source into a forecast and compare the result with GL actuals.
