A practical guide to finance reporting
Power BI for Finance Teams: Designing Month-End and Approval Reporting
Make month-end status useful: show who owns the next action, what is waiting for approval and which differences still need attention.
At a glance
Design around the next decision
- Give every item an ownerPreparation, review, escalation and report maintenance.
- Separate the measuresProgress, waiting time and reconciliation tell different stories.
- Make exceptions actionableA named owner, supporting evidence and an agreed next step.
On this page
Power BI for finance teams is most useful when it connects figures with the work needed to trust them. At month-end, a finance manager needs to know which reconciliations are ready, whose review is outstanding and which exceptions could hold up the close.
A completion percentage alone cannot answer those questions. A balance can match while approval is still outstanding; a task can be overdue without a monetary difference; missing data can make a report look healthier than it is.
Design the report around those distinctions, with agreed definitions and a clear route from each exception to its owner.
01 · Assign responsibility
Separate process ownership from report ownership
Name the finance process owner who agrees the close calendar, scope, status definitions and escalation rules. For each task, record a preparer, reviewer, current action owner and deputy. The person preparing a reconciliation may be different from the person who needs to act today.
Also name the data owner responsible for source quality and the technical owner responsible for the Power BI model, access and refreshes. A missing ledger extract and an overdue review need different routes to resolution.
Agree where updates and approvals are recorded. Power BI can present the position; an approval decision must be captured in the agreed workflow or source application. Microsoft documents Power Automate approvals and a Power Apps visual for adding app-based actions to reports. These require deliberate implementation, permissions and testing.
02 · Make status consistent
Define what each status actually means
Use a small set of agreed states, such as Not started, In preparation, Awaiting review, Returned and Approved. Define the evidence needed to enter each state and who can change it. Record approved exclusions separately.
Keep overdue, blocked and missing-evidence flags separate from status. An item can be both awaiting review and overdue. Treating these as competing statuses hides useful information.
Define completion explicitly: for example, approved in-scope tasks divided by all in-scope tasks for the selected period. Count distinct task instances, not approval-event rows. Show the numerator, denominator and exclusions so users can understand a change in the percentage.
Reopened items should return to the active queue. Retain the previous approval and the reason for reopening rather than silently overwriting the history.
03 · Define the clocks
Distinguish age from lateness
Pending-review age measures how long an item has waited since its current submission for review. Overdue time measures how far an open task has passed its due timestamp. A newly submitted item may already be overdue; an old submission may still be within its agreed deadline.
Choose calendar or business time, a time zone, cut-off and any holiday calendar. Define boundaries for age bands, for example less than two days, two to under five days, and five days or more.
Keep original submission time, current submission time and return history. Resubmission can start a new review interval without erasing the total elapsed time. Stop the relevant clock when the task leaves that stage, and label missing timestamps as unknown.
04 · Establish what should reconcile
Keep balance checks separate from sign-off
For each reconciliation, define the two values being compared: for example, an account balance in the general ledger and the corresponding supporting schedule. Align entity, account, period, currency, sign convention and source cut-off before calculating a difference.
Keep the raw difference, explained reconciling items and unresolved amount distinct. Agree any tolerance with the finance owner and specify whether it applies by item or account. A value inside tolerance should not automatically become approved unless the agreed control process allows it.
Show missing balances and mapping failures as exceptions. Replacing a missing value with zero can create a false match. Avoid netting positive and negative differences into a reassuring total, or combining currencies without an agreed conversion basis.
Preserve the source references and evidence used for review. Where the underlying balance changes after approval, agree when the task must be reopened.
05 · Build useful views
Give managers an overview and owners a work queue
The overview should show period and entity, approved versus in-scope tasks, overdue open items, pending reviews, unresolved differences and missing data. A drill-through queue should show task ID, current owner, due date, age, reason and evidence link.
Keep one task instance per period and reconciliation unit, with separate records for balances, approval events and individual exceptions. Joining every event directly to every balance can multiply rows and distort totals. Retain dated snapshots or sufficient event history to reproduce a prior cut-off.
Display both the report’s as-at time and source freshness. Microsoft’s refresh guidance explains that Import models need a data refresh to bring source changes into the model. A newly approved item may therefore remain in yesterday’s queue until the data updates.
Worked example · illustrative figures
Six tasks in a month-end review queue
This is a fictional example, not a Denova client result. A finance manager reviews six September-close tasks at 09:00 UTC on 5 October 2026. All six are in scope. Dates below are in October; ages use elapsed calendar time. All balances are illustrative GBP amounts on a consistent reporting basis.
Completion requires approval. Difference means ledger less supporting balance; the two non-zero differences remain unresolved at this cut-off.
| Task | Status and timing | Balance check and next action |
|---|---|---|
| UK bank | Status and timing Awaiting review Submitted 3 Oct, 09:00; pending 2 days. Due 4 Oct, 09:00; overdue 1 day. | Balance check and next action Ledger £248,000 Reviewer to confirm evidence and sign off. |
| UK accruals | Status and timing Returned Returned 4 Oct, 09:00. Due 5 Oct, 17:00; not overdue. | Balance check and next action Ledger £40,000 Preparer to explain or correct the difference, then resubmit. |
| DE intercompany | Status and timing Awaiting review Submitted 1 Oct, 09:00; pending 4 days. Due 3 Oct, 09:00; overdue 2 days. | Balance check and next action Ledger £610,000 Reviewer and entity team to investigate the difference. |
| UK payables | Status and timing Approved Approved 4 Oct, 09:00; closed before its due time. | Balance check and next action Ledger £78,000 Retain the sign-off and supporting evidence. |
| DE bank | Status and timing Approved Approved 4 Oct, 09:00; closed before its due time. | Balance check and next action Ledger £92,000 Retain the sign-off and supporting evidence. |
| DE payroll | Status and timing Not started Inputs missing. Due 5 Oct, 17:00; not overdue. | Balance check and next action Balances missing; difference not assessed. Obtain the ledger extract and supporting schedule; difference not assessed. |
The UK bank balance matches, but its review is still overdue. DE intercompany combines an overdue review with an unresolved difference. Payroll is not overdue yet, but missing inputs need attention before its deadline.
The absolute unresolved differences total £14,000: £2,000 plus £12,000. Netting them gives £10,000 and obscures the two issues. This is an exception measure, not a loss estimate or proposed journal. Payroll’s unknown difference is excluded from the amount and shown separately as missing data.
06 · Turn visibility into action
Give every exception a next step
For each exception, capture a reason, current owner, next action, target date and escalation route. Distinguish missing evidence, unresolved differences, mapping problems, workflow failures and overdue reviews. They should not all become an unexplained red indicator.
Prioritise using business impact, value, age and the close deadline. A matching balance awaiting review may need reviewer capacity; missing payroll inputs may need the source owner. Configure reminders and escalations in the agreed workflow where needed, and record reassignment and return decisions.
Test access for the intended finance audiences. Row-level security can restrict report data, but report access and authority to approve are separate controls. Check the linked app and evidence permissions as well.
Relevant client evidence
Reporting needs process knowledge and continuity
Denova’s global finance-team case study describes recurring monthly finance and commercial reporting, dashboard development, data-quality work and a bespoke balance-sheet reconciliation tool. It also explains how colleagues built knowledge of the client’s reporting cycles through continuing involvement.
A separate VAT workflow case study explicitly includes a Power BI report for task-status visibility within a solution using Power Apps, Power Automate and SharePoint. The team mapped the workflow and adjusted it as testing revealed additional cases.
These examples support the connection between finance reporting, workflow and operational ownership. The six-task example above is independent of both engagements.
Read how an ongoing engagement combined monthly reporting responsibilities with dashboards, a reconciliation tool and improvement work.
Copy into your project brief
Agree acceptance before the first live close
Test a returned item, a resubmission, a late approval, a reopened task, a missing balance and a stale source. Confirm both the totals and the action queues with the people who will use them. The worked example can serve as a small test dataset with known answers.
Use our Power BI reporting brief guide to develop the detailed requirements, and the support services guide to agree ownership after handover.
Plan the next step