Blog · Forecast and pipeline · Finance and FP&A teams
A forecasting dashboard compares saved forecast versions with actual results by business unit and horizon. Follow a worked US distributor example, a changed-input variation, and the checks that make the review reliable.
A dashboard forecast review compares saved forecasts with matching actuals, while keeping version changes separate from forecast errors. The useful views show what changed, where the eventual miss occurred, and which business owner must explain it. Every view needs the issue date, target period and scope visible beside the figure.
A finance team often asks two questions in the same meeting: why did the forecast move, and how well did the earlier forecast predict the result? The first compares versions. The second compares a version with actuals. Combining them in an unlabeled variance column makes a revision look like an error.
Keep budget comparisons separate as well. The budget versus forecast guide explains the different purpose of each baseline; a review should preserve that distinction even when all appear on the same page.
Select the business measure before designing the views. Revenue in dollars, demand in units and cash receipts are different series. NIST explains that time series can contain trend, seasonal variation and dependence across time. Comparable period definitions therefore matter as much as the display itself.
Keep the forecast snapshot file and actual-results export separate until the matching rules are agreed. Each snapshot row needs a stable business-unit identifier, measure, currency, target period, issue date, version status and amount. The actuals file needs the same business-unit, measure, currency and period identifiers, plus a close status.
Match actuals once to each eligible forecast row. Do not add actual amounts across versions: the same actual result is being evaluated against different estimates. Maintain an expected-submission list so an absent business unit appears as missing rather than silently disappearing from the total.
For this example, horizon means the number of month-end closes from the issue date to the target month-end. The September 30 snapshot for November has a two-close horizon; the October 31 snapshot has a one-close horizon. A company using weeks should state its own equally explicit convention.
Consider an illustrative US distributor reviewing November 2026 revenue after its books close. Both units report in USD. The first snapshot was approved on September 30, 2026, and the latest on October 31, 2026. The target period is November in both files.
| Business unit | September forecast (USD) | October forecast (USD) | November actual (USD) | Version change (USD) | Latest error (USD) | Absolute latest error (USD) |
|---|---|---|---|---|---|---|
| North | 600,000 | 640,000 | 620,000 | 40,000 | 20,000 | 20,000 |
| South | 400,000 | 420,000 | 380,000 | 20,000 | 40,000 | 40,000 |
| Total | 1,000,000 | 1,060,000 | 1,000,000 | 60,000 | 60,000 | 60,000 |
Use a declared sign convention throughout:
Version change = Latest forecast − Earlier forecast.
Forecast error = Forecast − Actual; positive means overforecasting.
North's version change is 640,000 − 600,000 = $40,000. Its eventual error is 640,000 − 620,000 = $20,000. These are separate facts: the upward revision exceeded the actual result, but the table alone does not establish why.
The latest forecast total checks as 640,000 + 420,000 = $1,060,000. Its change checks as 1,000,000 + 60,000 = $1,060,000. Its error checks as 1,060,000 − 1,000,000 = $60,000. Reconcile forecast totals to the approved snapshots and actual revenue to the closed ledger before interpreting the result.
| View | What it displays from the example | Decision it supports |
|---|---|---|
| Version comparison | North rises 40,000; South rises 20,000 | Ask the submitters for evidence behind the revisions |
| Actual versus selected forecast | North is 20,000 high; South is 40,000 high | Prioritize South's assumptions for review |
| Horizon comparison | September and October estimates remain separate | Assess usefulness at each decision lead time |
| Exception list | Unit, amount, explanation status and owner | Assign follow-up without hiding unresolved differences |
The September forecast happened to equal actual revenue in total. Underneath, North was 600,000 − 620,000 = −$20,000 and South was 400,000 − 380,000 = $20,000. The errors offset. A headline total alone would conceal both misses.
For a compact magnitude measure, sum absolute errors and divide by actual revenue. The latest version gives 60,000 / 1,000,000 = 6.0%; the earlier version gives 40,000 / 1,000,000 = 4.0%. Percentages here are rounded to one decimal place. This small example illustrates the display; it does not prove one horizon is generally better.
Evaluate genuine saved forecasts, rather than estimates revised after the outcome. The authors of Forecasting: Principles and Practice explain why evaluation needs observations excluded from forecast fitting. Keep deeper measurement work in the forecast accuracy and bias walkthrough.
Suppose South's November actual revenue is $420,000 instead of $380,000. Keep both forecast files and North's actual unchanged.
| Business unit | Latest forecast (USD) | Revised example actual (USD) | Error (USD) | Absolute error (USD) |
|---|---|---|---|---|
| North | 640,000 | 620,000 | 20,000 | 20,000 |
| South | 420,000 | 420,000 | 0 | 0 |
| Total | 1,060,000 | 1,040,000 | 20,000 | 20,000 |
The version change remains $60,000 because neither forecast changed. The latest error falls to $20,000, and absolute error divided by actual revenue becomes 20,000 / 1,040,000 = 1.9%, rounded. South leaves the error exception list, while North remains. This is why actuals corrections should carry a date and explanation without overwriting approved forecasts.
For product planning, demand forecasting establishes what quantity is being forecast, while retail demand forecasting addresses store and product decisions. Link those operational reviews from the business-unit exception instead of filling the finance view with unrelated detail.
The dashboard owner should be FP&A, with accounting confirming actuals and business-unit leaders owning assumption changes. An explanation becomes useful when it names the affected rows, the changed assumption, the evidence and the next decision. A chart by itself supplies none of those approvals.
Bring approved forecast snapshots and the matching actual-results export; Covirage maps the columns, and its tools compute and check version changes and forecast-versus-actual differences. The external AI model explains the results with every figure traced to its rows. Create a free Covirage account and bring a sample of your own export.
See Covirage for finance teams for the supporting finance use cases.
Include the selected version, issue date, target period, horizon, forecast amount, matching actual amount and business unit. Add a version-change view and an exception list with named owners. Display missing submissions and unclosed actual periods explicitly so users can judge whether a comparison is ready.
Match the review to the business decision and the availability of reliable inputs. Preserve every approved snapshot before loading the next one. Refreshing a display more often does not create a useful accuracy comparison if the target period has not closed or actuals remain incomplete.
A forecast is an estimate for a future period under stated assumptions. A dashboard is a way to inspect estimates, revisions and results. It can reveal which assumptions need review, but displaying a number does not establish how that estimate was produced or approved.