Construction Project Reporting in Power BI
The monthly report that never quite agrees
Most construction businesses produce a project report every month, and most of them produce it by hand. Someone exports cost to date from the accounting system, someone else pulls progress from the scheduling tool, a third person copies the safety statistics out of the incident register, and the three sets of numbers are stitched together in a spreadsheet the night before the review. By the time it reaches the project control group, the cost figure is a fortnight old and nobody can explain why the schedule says a package is 80 per cent complete while the cost says 60.
The cause sits in the systems, which were never designed to agree. The accounting system knows dollars committed and invoiced. The project management tool knows the schedule and claimed progress. The field app knows timesheets, dockets and safety events. Each is right in its own terms, and each uses its own codes for the same work. The monthly report is an attempt to reconcile them under time pressure, which is why it is slow to produce and easy to distrust.
This post is about building that reconciliation once, properly, in Power BI, so the report produces itself and the numbers tie back to their source. The hard part is not the dashboard. It is the data model underneath it, and getting the codes to line up across systems that have spent years drifting apart.
Why cost, progress and safety refuse to line up
Walk into the data and the mismatch is always the same handful of causes. Fixing the report means fixing these, not building a prettier chart on top of them.
The first cause is coding. The accounting system books cost against a cost code, the schedule tracks activities against a work breakdown structure, and the two were set up by different people at different times. A single activity on site maps to three cost codes, or one cost code covers four activities, so there is no clean join between dollars and progress. Until the mapping exists, any dashboard that puts cost and progress side by side is comparing two things that do not refer to the same work.
The second cause is timing. Cost is recognised when an invoice is processed, which can lag the work by weeks. Progress is claimed when the work is done. Put the raw figures together without aligning the periods and every project looks like it is underspending, right up until the invoices land and it does not.
The third cause is that safety and quality data sit in a separate world entirely, often in a field app or a standalone register, keyed by project and date but not by the cost code or activity. Leaders want to see safety performance against the work being done, and the data will not join without a shared project and calendar structure that most businesses have never built.
Three systems into one model
The fix for all three is a shared spine: one project and work breakdown structure, one calendar, and a mapping table that translates each system's codes into that spine. Build the spine and the systems can keep their own codes while the model reconciles them. Skip it and you are back to a spreadsheet stitched together at midnight.
What a reconciled model does that a spreadsheet cannot
Once cost, progress and safety share a spine, the report changes character. Earned value becomes a live calculation rather than a monthly archaeology project. You can see cost performance and schedule performance against the same work package on the same day, with safety events overlaid on the activities that produced them. More to the point, every number traces back to the system it came from, so when a project manager challenges a figure in the review you can drill from the dashboard to the source transaction rather than defending a spreadsheet nobody trusts.
Manual monthly pack and a reconciled model
| Metric | Hand-built spreadsheet | Power BI model | Improvement |
|---|---|---|---|
| Time to produce | Two to three days | Refreshes on a schedule | Automated |
| Cost data age at review | Up to a fortnight old | Last sync, dated | Current |
| Cost against progress | Different codes, no join | Same WBS, reconciled | Aligned |
| Challenge a number | Rebuild to check | Drill to source | Traceable |
| Multiple projects | One spreadsheet each | One model, filtered | Consistent |
The consistency across projects is the quiet win for a business running more than a few jobs at once. When every project is reported the same way from the same model, the portfolio view is real rather than an average of spreadsheets that each count things differently. A national operations manager can compare sites on the same basis, and a problem project shows up in the same place every month instead of being buried in a format only its own team understands.
Build the spine before you build the dashboard
The order of work matters, because it is tempting to start with the visuals and discover the data will not support them. The reliable sequence starts underneath.
A reporting build that holds up
Mapping the codes is the step businesses want to skip and the step that decides whether the project succeeds. It is unglamorous work: sitting with the people who own the cost structure and the people who own the schedule and agreeing, line by line, how one translates to the other. Done once and maintained, it is the asset that makes every future report possible. This is the same integration discipline that governs any job where separate business systems have to be made to talk to each other, and it is worth treating as its own piece of work rather than an afterthought to the dashboard.
Connecting the sources is a question of what each system can expose. Modern accounting and project tools offer an API or a scheduled export. Older or on-premise systems may need a database view or a nightly file drop. Either works for reporting, because a project report refreshed each morning is current enough; you are not building a live control room. The field and safety data is often the fiddliest, because it lives in an app chosen by operations rather than finance, but the same principle holds: reach it by API or export, land it in the model, and key it to the shared spine.
Modelling and reconciliation is where the earned value logic lives, where periods are aligned so cost and progress refer to the same window, and where the safety data is joined to the work. Only then do the dashboards go on top, and the final step is verification: every headline number on the dashboard checked against the source system until the project control group believes it. That belief is the whole point, because a report nobody trusts gets rebuilt by hand anyway and the investment is wasted.
Where AI earns its place, and where it does not
Reporting is a data and modelling problem first. AI is useful at the edges of it, and overselling that is how reporting projects lose credibility. Be honest about the split.
Reporting task: model logic or AI?
The figures that drive decisions, cost performance, schedule performance, earned value, must come from deterministic logic in the model, where the same inputs always give the same answer and an auditor can follow the calculation. AI has no place in the arithmetic. Where AI does help is the unstructured material around the edges: matching a foreman's free-text note to the activity it refers to, pulling the quantity off a scanned delivery docket so it does not have to be rekeyed, or drafting the written commentary that accompanies the numbers so the project manager starts from a draft rather than a blank page. In each of those cases a person confirms the output before it counts, which is the same shape of control that any responsible AI build keeps: the AI drafts, a person approves, and nothing unchecked reaches a report that leaders act on. The deeper work of getting a messy export ready for the model, the cleaning and reshaping, is ordinary process automation and pays for itself long before any AI is involved.
What a reconciled report returns
Grounded in work that has actually been done
This is not a theoretical build. Solve8 delivered carbon and sustainability reporting in Power BI for a Tier 1 infrastructure contractor in the VINCI group, pulling data from operational systems into a model the business could rely on and report from. The mechanics are the same as project controls reporting: reach the source systems, agree a shared structure, reconcile the numbers, and verify every figure against where it came from. You can read the detail in our Tier 1 infrastructure reporting case study, which is the documented client work this approach rests on.
The field data side connects to another piece many contractors already run. If your subcontractors and crews log work through a job management platform, the choice of platform shapes what reporting can reach, which is the subject of our comparison of ServiceM8, Tradify and simPRO for field service businesses. And because cost is the figure most often fought over in a review, the quality of the data coming out of the accounting system matters as much as the model on top; the same reasoning applies in our guide to AI automation for accounting firms across Xero and MYOB, where clean, coded financial data is the starting point for anything downstream.
The honest next step
A project reporting build is scoped work rather than a product you switch on. The first conversation is short and specific: which systems hold your cost, schedule and field data, how far apart their codes have drifted, and what the monthly pack has to show the control group. From there the mapping effort can be estimated with some confidence, and the build phased so you see a working reconciled report on your real projects before committing to the full portfolio.
If your monthly report takes days to assemble and still gets argued about in the room, the cause is almost always the data model underneath it, and that is fixable. This is the kind of groundwork an Australian AI and data consultancy does before anything clever goes on top, and the first scoping conversation costs you nothing but an hour and a list of your systems. Bring the report you produce today and we will show you where it is fighting itself.
Common Questions
Why do cost and progress never match on construction reports?
They are coded differently. The accounting system books cost against cost codes, while the schedule tracks claimed progress against a work breakdown structure, and the two were usually set up separately with no mapping between them. Cost is also recognised when invoices are processed, which lags the work by weeks, so raw cost looks lower than progress until the invoices land. Both issues are fixed by building a shared structure and aligning the reporting periods before the two figures are compared.
Can Power BI pull data from our accounting and project systems automatically?
In most cases yes. Modern accounting and project management tools expose an API or a scheduled export that Power BI can connect to and refresh on a timetable. Older or on-premise systems can be reached through a database view or a nightly file export, which is current enough for a report that refreshes each morning. The effort is less about the connection and more about mapping each system's codes to a shared structure so the data reconciles once it arrives.
How long does it take to build reliable project reporting?
For a defined set of systems, a first reconciled report on real projects is realistic within about eight weeks, with the early weeks spent mapping codes and connecting sources rather than building dashboards. The mapping is the step that decides success and cannot be rushed. Once the model and the shared structure exist, adding further projects or new views is fast, because the hard reconciliation work has already been done.
Where should AI be used in construction reporting, and where should it not?
The numbers that drive decisions, such as cost performance, schedule performance and earned value, must come from deterministic model logic that always gives the same answer and can be audited. AI should stay out of that arithmetic. AI is useful on the unstructured edges: matching free-text site notes to activities, extracting figures from scanned dockets, and drafting the written commentary around the numbers. In each case a person confirms the result before it is relied on, so the report stays trustworthy.
Do we need to replace our existing construction software to do this?
No. The reporting model sits on top of the systems you already run and reads from them. Each system keeps its own codes and its own role, and the model translates them into a shared structure for reporting. Replacing software is a separate decision with its own case, and it is usually better made after the reporting shows clearly where the current tools help and where they get in the way.
Related Reading
- Tier 1 infrastructure reporting in Power BI: a case study
- System integration: making separate business systems talk
- ServiceM8 vs Tradify vs simPRO for field service businesses
- AI automation for accounting firms across Xero and MYOB
- Process automation for Australian businesses
- AI strategy for Australian organisations