Ask a board what they want from a finance dashboard and they will say "everything". Watch what they actually look at and it is five numbers, every time. This article sets out those five, explains the modelling decisions that make them trustworthy in Power BI, and covers the mistakes that make finance teams give up on dashboards and go back to Excel.
The five numbers
Revenue against plan and prior year. Not just the total, but by the dimension the business is actually managed on: product line, customer segment, region or entity. The dashboard should answer "where did the variance come from?" in one click.
Gross margin, in pounds and as a percentage. Margin is where pricing, cost and mix problems first show up. It needs to be defined once, consistently, with the cost of sales rules written down.
Operating cash and runway. Closing cash, the movement in the month, and for growth businesses, months of runway at the current burn. For businesses with debt, headroom against covenants sits alongside.
Working capital. Debtor days, creditor days and stock days, with the ageing behind them. This is the number that explains why profit and cash have diverged.
Headcount and people cost. Full-time equivalents against plan and the fully loaded cost, because in most businesses people are the largest controllable cost and the hardest to reverse.
Everything else belongs on a second page or in the drill-through. A dashboard that leads with these five, and lets a director drill into any of them, will get used. One that opens with forty tiles will not.
Modelling decisions that make the numbers right
The dashboard is the last ten percent of the work. The other ninety is the data model, and in Power BI that means a star schema with a clean fact table and well-designed dimensions.
Build a finance fact table at the right grain. Usually one row per general ledger transaction or per account-period balance, with keys to account, cost centre, entity, period and, where available, customer and product. Resist the temptation to import the trial balance report; import the transactions and build the balances.
Use a proper chart of accounts dimension. The account dimension should carry the reporting hierarchy: statement, category, sub-category, account. This is what lets a single measure produce the P&L, the balance sheet and the departmental view without separate logic for each.
Model periods explicitly. A date table with fiscal year, fiscal period and flags for the current and prior period. Most finance measures compare periods, and period logic written into individual measures is where inconsistencies breed.
Handle sign conventions once. Ledgers store credits and debits with signs that are correct for accounting and confusing for reporting. Decide once, in the model, how revenue and cost are signed for display, and apply it in the fact table rather than in forty measures.
Define every measure once. Gross margin is a single measure, with a single definition, used on every page. If a second definition is needed for a specific purpose, give it a different name. The quickest way to lose trust in a dashboard is two tiles that both say margin and show different numbers.
Build budget and forecast as separate scenario facts. Actual, budget and forecast at the same grain, with a scenario dimension. Variance measures then compare any two scenarios without bespoke logic.
Reconciliation is a feature, not a check
Every refresh should prove itself. Store control totals from the source system (total revenue, total cost, closing cash by entity for the period) and compare them with the model on each load. Show the result on a hidden or admin page. When the numbers do not tie, the finance team should know before a director does.
This single discipline is what separates dashboards that replace the Excel pack from dashboards that sit beside it.
Mistakes that kill finance dashboards
Building from reports rather than data. Importing the exported P&L report gives you a dashboard that can only show what the report showed. Import transactions.
Letting measures multiply. One author per model, or a reviewed measure library, or both. Fifteen variations of revenue will appear within a year otherwise.
Skipping row-level security. Budget holders should see their own cost centres and nothing else. Without security, the finance team ends up publishing separate reports per department, which recreates the problem the dashboard was meant to solve.
No owner for the refresh. Someone has to know when a refresh fails and why. Set up alerts, and name a person.
Designing for the finance team instead of the board. The finance team knows where everything is. Directors need the five numbers first, plain labels, and a path to the detail.
Where the effort goes
A typical finance reporting build spends two to three weeks on discovery and design (agreeing the five numbers, the dimensions and the definitions), four to eight weeks on the data model and pipelines, and two to three weeks on the report pages and training. Clients are sometimes surprised that the visuals come last. The order is deliberate: the numbers have to be right before anyone argues about chart colours.
If your current Power BI reporting is not trusted or not used, the fix is almost always in the model and the reconciliation rather than the visuals. That is where we would start.