If your finance team has a Power BI workspace, it has a close cockpit somewhere in it. If you ask a controller when they last opened it, the answer is honest: rarely. Close cockpits fail for a small set of reasons, and the cockpits that survive fix those reasons one by one.
Three failure modes
- Lagging refresh. A close cockpit refreshed nightly is useless during close, because the questions are 'what changed in the last hour?'
- Wrong audience. Cockpits built for the CFO get viewed once a quarter. Cockpits built for the close team (accountants closing the books today) get viewed every day of close week.
- Drilldown gap. Knowing intercompany is behind doesn't help unless you can see which entity, which JE, which person.
The pattern that survives
A useful close cockpit has three things: a 15-minute refresh during close week, a single page that fits a controller's eyeline (no scrolling, no tabs), and one-click drilldown into the offending workpaper or journal entry. Everything else is decoration.
What goes on the page
- Close countdown: days remaining, with a target line.
- Status by ledger / entity: green / amber / red, with hover for the blocker.
- Top 5 outstanding journals: owner, age, dollar magnitude.
- Reconciliation pass rate: by reconciliation type, with last-refresh time.
- Exception queue: bot exceptions with severity and owner.
How long it takes
The time from a clean event log to the first usable cockpit depends mostly on where the data lives: faster if it is already in a warehouse, longer if you are modelling from scratch. The first version is always slightly wrong; expect a tuning period after the first close, where the controller tells us which numbers are off and we fix them.
After a couple of closes, the cockpit becomes the artifact the leadership team consults during close week, and the close-day debates that used to happen by email start happening on the page.