Building an Auditable Project Data Model Across ERP, Site Reports and BI

EPC projects generate disputes, and disputes are settled on evidence — the dated instruction, the certified quantity, the cost incurred, the programme impact. The problem is that each of those lives in a different system, captured by a different person, in a different format, and when the four are assembled for a claim they disagree: the ERP cost does not match the site-measured quantity, the variation date in the email is not the date in the cost system, the programme was revised but the baseline is lost.

An auditable project data model exists to make the project tell one story that can be proved. It is not a dashboard — it is the traceable record underneath the dashboard, where every figure can be followed back to the source document and the moment it was captured. For a contractor, that record is simultaneously a management tool and a legal asset, and most do not have it because their systems were never joined.

The commercial reality of an EPC project is distributed by design. The ERP holds cost, procurement and billing. Site reports and diaries hold what physically happened — progress, labour, plant, instructions received, delays and their causes. The programme holds planned versus actual and the critical path. And BI sits on top reporting whichever of these it can reach. Each is maintained by different people with different incentives and different update rhythms.

Because they are separate, they drift. The site knows a variation was instructed on the 3rd; the cost system records it when the paperwork catches up a fortnight later; the programme is revised without preserving what it replaced. Each system is internally plausible and collectively contradictory, so when a number is challenged nobody can prove which version is right. Joining them into one model with a shared project structure — common project, WBS, cost code and date keys — is the first act of making the project auditable.

What makes a project data model auditable is not that it holds the numbers — a spreadsheet holds numbers — but that every number carries its provenance: the source system, the source document, the person, and the timestamp it was captured. A certified quantity traces to the measurement record; a variation cost traces to the instruction and the cost lines; a progress figure traces to the site report that recorded it. The lineage is preserved immutably, so a figure cannot be silently changed without a trace.

This is the difference between data that informs a decision and data that can defend one. In a claim or an audit, 'the system says USD 240,000' is weak; 'USD 240,000, traceable to these three cost lines against this instruction dated the 3rd, captured in the site diary that morning, unchanged since' is strong. Building lineage in from the start — rather than trying to reconstruct it after a dispute arises — is what turns the model from reporting into evidence.

The model unifies the four sources into a consistent structure keyed on the project hierarchy — project, work breakdown structure, cost code, period — so cost, progress, variations and instructions can be joined and reconciled rather than compared by hand. Raw source data is landed and preserved as captured (the immutable record), then conformed into the shared structure, then served to reporting — a medallion pattern that keeps the auditable raw layer intact beneath the cleaned analytical one.

On the Microsoft stack this is a Fabric lakehouse: the ERP, site-capture and programme data land in OneLake, are modelled through bronze-silver-gold layers that preserve lineage, and are governed with Microsoft Purview for cataloguing, classification and access control. The bronze layer is the evidentiary record — source data exactly as received, never overwritten — and everything above it is traceable back to it. That architecture gives the contractor both a live management view and a defensible audit trail from the same foundation.

The immediate payoff is claims and disputes: a variation, delay or disruption claim built on a traceable record is faster to assemble and far harder to challenge, because the evidence is already joined and dated. Contractors routinely lose legitimate claims not because they were wrong but because they could not prove them in time — the auditable model removes that failure mode.

Beyond disputes, the same record powers honest project control — real earned value against a preserved baseline, cost-to-complete grounded in reconciled actuals, and portfolio reporting the finance director can trust because it traces to source. It also compresses external audit, because the auditors can follow the lineage themselves rather than requesting reconciliations. One model, built once, serves management, finance, commercial and legal — which is why it belongs on a governed foundation rather than in another reporting silo.

The model cannot create evidence that was never captured. If the site did not record the instruction, or recorded it without a date, no data architecture can manufacture the provenance after the fact — the auditable model is only as good as the discipline of capture at source. Site-level capture, often the weakest link because it depends on busy people on a live project, is the real prerequisite, and improving it is frequently the first and hardest part of the work.

It is also a foundation project, not a quick report: joining ERP, site and programme data on a common structure with preserved lineage is genuine data engineering, and a contractor expecting a dashboard in a fortnight will be disappointed. And governance has to be real — an auditable model with loose access control or mutable raw data is not auditable at all, so the Purview-and-medallion discipline is load-bearing, not optional polish.

Start with the capture discipline and one project's worth of joined data.

• Confirm instructions, variations and progress are captured at source with dates and authors — fix the site-capture gap first, because the model depends on it
• Define the shared project structure (project, WBS, cost code, period) that the ERP, site and programme data will be keyed on
• Land source data immutably (a bronze layer in a Fabric lakehouse) and preserve it exactly as received as the evidentiary record
• Conform and reconcile into the shared model, keeping lineage from every figure back to its source document and timestamp
• Govern it with Purview — cataloguing, classification, access control — so the record is genuinely auditable, then report on top