One reporting system across thirteen dashboards
For an Australian accounting and advisory firm
I designed and built one consistent Power BI reporting system that brings fragmented data together, applied across thirteen dashboards, from job pipeline tracking to executive oversight.
The client is anonymised. Dashboard layouts are redrawn without client data; no figures, names or branding are shown.
13 dashboards. One connected reporting architecture.
Reporting data was split across FYI, Xero/XPM, and manual spreadsheets — no single place to see whether the firm was on pace.
One Power BI architecture applied across 13 dashboards — practice operations, financials, client communication, and executive roll-ups.
Designed the architecture end to end: data sourcing, modeling, DAX business logic, dashboard design, and documentation.
One reporting architecture across multiple operational and financial systems — not thirteen separate dashboards.
Is the firm on pace this month?
The firm’s reporting data was spread across FYI, Xero/XPM, and manually maintained Excel/SharePoint inputs. Practice management, tasks, and documents sat in FYI. Accounting and job data sat in Xero and XPM. Revenue and collection targets existed as numbers in a spreadsheet, updated by hand.
Each system did its own job well. None of them, on its own, could answer a simple question: is the firm on pace this month?
Answering that meant checking several systems plus a spreadsheet and reassembling the picture manually — a process that rarely produced the same answer twice, and was often out of date by the time it was finished.
The firm needed one consistent place to see how the practice was actually running, built on logic that meant the same thing wherever it appeared.
Thirteen dashboards, one connected architecture
I designed and delivered a reporting ecosystem spanning thirteen Power BI dashboards, using shared architectural patterns and reusable components across accounting, practice management and operational data. The dashboards run on multiple models, built to the same conventions; what connects them is the architecture underneath.
The number thirteen matters less than what’s underneath it. Every dashboard connects to its data the same way, models it with the same conventions, and documents itself to the same standard. That consistency is the actual system; the thirteen dashboards are what it looks like applied to thirteen different business questions.
The business functions it covers
Select a group to see what it covers.
Executive roll-ups
The operational and financial views combined into one management picture.
- The Quarterly Review reads client-communication figures from the Client Communication fact table instead of recalculating them.
Data architecture & sources
Three different kinds of data feed the system, each handled differently:
FYI, through its REST API
Tasks, documents, jobs and clients. The connection logic — authentication, paging through results, parsing the response — is written once as a reusable query and called wherever FYI data is needed, rather than rebuilt per dashboard.
Xero and XPM, through a SQL warehouse
Both are mirrored into a third-party SQL data warehouse, which the dashboards query directly. Joining financial data from Xero with practice and lead data from XPM happens in a single query, rather than across two separate APIs with two different data shapes.
Business inputs, from SharePoint
Targets and other maintained business inputs come from Excel files on SharePoint. These are business inputs that don’t exist as data anywhere else in the connected systems.
Calculated once, reused
The Quarterly Review needs client-communication metrics. Rather than recalculating them, it reads from the same fact table the Client Communication dashboard already produces.
The same rules, applied consistently
Period-aware targets
Revenue and collection targets follow the firm’s financial year and adjust automatically to whatever period is selected, rather than comparing actuals against a flat annual figure.
Timesheet compliance, calculated per period
Expected hours are calculated for the period and people selected, then compared against logged hours, so compliance reflects the actual working calendar instead of a flat assumption.
Stalled-work alerts
Jobs that stay in one stage for longer than an agreed threshold are flagged automatically, so they surface before they become overdue.
Client response-time tracking
Client correspondence is grouped into conversations so that response times can be measured in both directions — built on a document-management platform that has no built-in concept of a conversation.
Four dashboards, redrawn
Four of the thirteen, chosen to show the range of what one architecture supports.
Each layout is redrawn from the production dashboard. Panel titles and structure are real; bar lengths and shapes are illustrative, and labels that could identify the client are generalised.
Partner & Manager Overview
The executive view, and the clearest evidence that the architecture holds together end to end: job completions, revenue, collections, and lead conversion, broken down by team and by accountant, month-to-date and year-to-date, on one page.
- 1The same five measures in two bands: month to date above, year to date below.
- 2Every measure is plotted against its target: the dashed outline beside each bar.
- 3The bottom row surfaces the exceptions: the lowest-revenue client groups and the slowest payers.
- 4The date filter is labelled so readers know it doesn't change the MTD and YTD figures.
Invoices Collected
Collections tracked against a financial-year-aware target, with the target and variance recalculating depending on the period selected — the dynamic target logic described above, in the form a partner would actually use.
- 1Targets and variance recalculate for whichever period is selected, not just a flat annual figure.
- 2Year to date and month to date side by side, each defaulting to the latest period.
- 3Highest and lowest collecting clients, to show concentration and slow payers.
- 4An Audit page is one click away, for reconciling totals against source data.
Timesheet Audit
Compliance measured against expected hours calculated from actual working days in the selected period, not a flat assumption.
- 1Expected hours are calculated for the selected period, not assumed as a flat number.
- 2Logged against expected hours for every person and every week, with compliance colour-coded.
- 3An instruction on the page explains which visuals the week filter affects.
- 4A separate audit page for checking unusual entries.
Client Communication
Response-time performance in both directions, broken down by client and by staff — the most involved piece of data-matching in the system.
- 1Response time is measured in both directions: client to firm, and team to client.
- 2Recent and prior periods side by side, to show whether volume is rising or falling.
- 3Every unanswered client email, with how long it has waited, an aging bucket and an escalation flag.
- 4The share of emails answered on time, answered late, and not answered.
Documentation as part of the deliverable
Every one of the thirteen dashboards ships with a Read Me page documenting what it does, exactly how each figure is calculated, and its own known limitations, stated directly rather than left for someone to discover. Several of the dashboards handling the most complex source-matching also include a dedicated Audit page, built for reconciling the numbers against source data.
Audit pages
For the dashboards with the most complex source-matching, a dedicated page for reconciling totals against the source data, one click from the main view.
The section headings are the real ones. Their contents describe internal business rules, so they stay private.
The known boundaries, stated plainly
None of this is presented as flawless, and the dashboards themselves don’t either. Each one states its boundaries; in general terms, they are:
Linking records between systems depends on the source data being consistent. Where it isn’t, records are flagged for review rather than allocated silently.
Some business inputs live in maintained files. They need an owner, because a stale file affects reporting until it’s corrected.
Data refreshes on a schedule during the day. Anything entered after the last refresh appears in the next one.
The system reflects current state; reconstructing what a number looked like at a past point in time isn’t currently supported.
One consistent picture of the practice
The system gives the firm one consistent place to monitor:
- Financial performance — revenue and collections against financial-year targets
- Operational workload — job pipeline, completed jobs, team tasks
- Compliance status — work approaching or past key deadlines
- Timesheet compliance — logged hours against expected hours, per staff member
- Client responsiveness — how quickly the firm and its clients respond
- Management-level performance — a combined view across all of the above, by team and by accountant
These reporting questions previously required data from different systems and inputs to be brought together. Built on one architecture, they’re now reviewable as a single, consistent picture.
My contribution
I designed and built the system end to end, from data integration through to delivery.
Designed the architecture end to end: how each source connects, how data is shaped and modelled, and how every dashboard is documented.
Connected FYI through its REST API with a reusable connector, Xero and XPM through a SQL warehouse, and maintained inputs from SharePoint.
Built the Power Query transformations, with connection and cleaning logic written once and reused.
Modelled the data across all thirteen dashboards, with multiple models built to the same conventions.
Wrote the DAX behind period-aware targets, timesheet compliance, stalled-work alerts and response-time tracking.
Designed and built the dashboards, from operational views to executive roll-ups.
Built audit views for reconciling against source data, and traced and resolved data-integrity issues found during the build.
Delivered the system in three months, working with the client’s stakeholders, with a Read Me built into every dashboard.
What I’d improve next
A historical snapshot layer, so past figures could be reconstructed rather than only showing current state. A more structured process for maintained business inputs, to reduce reliance on hand-updated files. More robust matching of records across systems. And extending the pattern already proven in Quarterly Review — reusing an existing fact table instead of rebuilding it — to reduce the remaining pockets of overlapping logic across the thirteen dashboards.
Have reporting spread across systems like this?
Tell me what you’re working with. I’ll tell you what I’d look at first.