CFO dashboard in Power BI: what a finance leadership page should carry

Most CFO dashboards fail for the same reason: they are the monthly pack pasted onto a screen. Twelve pages of charts, every measure the finance team can calculate, and no answer to the question the CFO actually opens the report with, which is usually some version of "is anything wrong, and where". A finance leadership page is a different object from a management pack. It carries fewer measures, each one defined once, and it is built so that the person reading it can get from a number they do not like to the transactions behind it without asking anyone.

This article sets out what that page should carry, how each measure should be defined, and what has to be true of the Power BI model underneath it. The examples assume a mid-sized UAE business running a finance system such as Tally, Zoho Books, Odoo, SAP Business One or Dynamics 365 Business Central, with a budget in Excel and at least one other entity to consolidate. That describes most of the businesses this site is written for.

Six measures, not sixty

A leadership page earns its place by being short. Six measures is a reasonable ceiling for the top of the page; everything else is a drill path beneath one of them. The six that belong on almost every CFO page are these.

• Cash and the thirteen-week view. Closing bank balance by entity and currency, then the forward view built from the receivables ledger, the payables ledger and the payroll calendar. In a business that holds post-dated cheques, PDCs in hand and PDCs issued are shown separately from cash, because they are not cash until they clear.
• Revenue against budget and against last year. Month, quarter and year to date, with the comparison basis stated on the visual. Which comparison matters depends on the business; a hospitality group cares about the Ramadan-shifted comparable, a trading business about the same trading days.
• Gross margin after landed cost. Not the margin the sales system reports, which usually ignores freight, duty, clearing and warehouse handling. Margin after landed cost is the figure that tells the CFO whether a product line or a customer is worth keeping.
• Operating expenses by cost centre against budget. With the variance shown as an amount and a percentage, and the drill path going to the general-ledger lines, not to a summary someone typed.
• Working capital: debtor days, creditor days and stock days. Each defined in writing, because there are at least three accepted ways to calculate debtor days and a dashboard that switches between them silently is worse than none.
• The close itself. Which entities have closed, which reconciliations are outstanding, and whether the VAT control accounts reconcile to the return that will be filed. That last one is a reporting check, not tax advice; the dashboard shows whether the ledger and the return agree, and a tax agent decides what to file.

Every measure needs a written definition

The reason board packs drift is that the definitions live in people's heads and in the formulas of one workbook. When the controller who built the pack leaves, the definitions leave too. In Power BI the definition of a measure is a DAX expression in the model, which is better, but it is still invisible to the reader unless it is written down somewhere they can see it.

The practical answer is a definitions page in the report and a description on every measure in the model. The definitions page states, for each of the six, what is included, what is excluded, which comparison period is used and where the number can be reconciled to. Gross margin after landed cost, for example, would state which cost elements are in landed cost, whether duty is allocated at the shipment or the line, and that the total reconciles to cost of sales in the ledger. This page is the one that finance directors check first when a number looks wrong, and its absence is the most common reason a new dashboard is not trusted.

Multi-entity is the normal case

In Dubai and the wider UAE the usual reporting entity is a group: a mainland LLC, a free-zone company and sometimes a third for a branch or an overseas trading arm, each on its own set of books, sometimes on different systems. A CFO page that only shows one entity is a page for a subsidiary, not for the CFO.

The model therefore needs an entity dimension from the start, a single chart of accounts mapping that every entity's ledger rolls up to, and a currency handling rule that is written down. Because the dirham is pegged to the US dollar, USD purchases are simple; EUR, CNY and INR purchases are not, and the rate used for the management view (transaction rate, month-end rate or a budget rate) should be one rule applied everywhere. The same entity dimension is what makes it possible to show the free-zone entity and the mainland entity separately when the reader needs them apart and together when the reader needs the group - which, since the introduction of Corporate Tax, is a distinction finance teams are asked about more often. The dashboard shows the split; it does not decide the tax treatment.

Drill-through beats detail pages

A CFO does not want a debtors page; a CFO wants to click a debtor-days figure that has moved and see which customers moved it. That is a drill-through in Power BI: a right-click from the summary figure that opens a detail page filtered to whatever was clicked. Built well, the leadership page is one screen and the detail pages are only ever reached through it, so the report stays short and the answers stay one click away.

The drill path should always end in transactions. If the last page a reader can reach is still a summary, they will go back to asking the finance team for an export, and the dashboard has not replaced anything.

What has to be true of the model

None of the above works on a model built by importing the trial balance into Power BI and writing measures over it. The model needs a date table with the fiscal calendar and the comparison logic; a chart of accounts dimension with the management roll-ups; an entity dimension; a fact table of ledger lines at the level the drill path needs; and a budget table joined to the same accounts and periods as the actuals. It needs to refresh on a schedule from the finance system rather than from a monthly export, and it needs row-level security if the same report is going to serve entity managers as well as the group CFO.

The reason to build it this way is not elegance. It is that a CFO dashboard is only useful if the CFO believes it, and belief comes from being able to reconcile every number on it to the ledger. When the model is built to reconcile, that check takes a minute. When it is not, it takes a week, and the pack goes back to Excel.

Where to start

If the pack is still assembled by hand each month, the first decision is whether to automate it where it is or move it. The Excel to Power BI migration page on this site sets out how that choice is made and what a fixed-price migration includes. If the finance model already exists and the question is only what the leadership page should show, the six measures above are a reasonable first scope, and a thirty-minute call at no charge is the quickest way to find out what your ledger can support today.