ProjectSight holds the project story. Your ERP holds the financial story. Most contractors connect the two by hand, the week before an owner meeting, and the resulting deck is out of date the moment somebody asks a question it did not anticipate.
Key Points: ProjectSight and ERP Reporting
- The split is by design. Project management systems track commitments and progress. ERPs track posted transactions. Neither is trying to be the other, which is why the join falls to a person.
- The integration is not the hard part. Moving data between two systems is tractable. Getting cost-to-complete, change order impact, and budget variance to reconcile across both is where the timeline goes.
- Poor project data is measurably expensive. Miscommunication and bad project data account for 48% of all rework on US construction jobsites, costing the industry more than $31 billion in a single year (PlanGrid and FMI, 2018).
- A built deck and a queried dashboard fail differently. A deck is accurate until the follow-up question. A model handles the follow-up with a filter.
- Custom builds carry key-person risk. When the person who understood the model leaves, the model leaves with them.
- The Foundation Pack is infrastructure, not finished reports. It delivers pipelines, a governed lakehouse, and metric stores your team builds the reporting on.
Two systems, two versions of the same project
RFIs, submittals, change orders, daily logs, and budgets live in ProjectSight. Actuals, accounts payable, payroll, and billings sit in the ERP. So a project engineer spends the night before the owner architect contractor meeting stitching them into a deck.
Neither system is doing anything wrong here. ProjectSight runs the project side well, the ERP runs the financial side well, and the gap between them is a boundary rather than a defect. It only becomes a problem when somebody has to report across it.
That deck is usually good. The problem is that it is built rather than queried, which means it is out of date the moment the owner asks a question it did not anticipate. And the questions owners ask are rarely the ones the slide was designed around. They ask what a pending change order does to the forecast. They ask whether the number on slide four includes committed cost. They ask why last month’s percent complete moved.
Each of those is answerable. None of them is answerable from a static deck without another night’s work.
What lives where
| In ProjectSight | In the ERP | Needs both to answer |
|---|---|---|
| Budgets and forecasts | Posted actual cost | Cost to complete |
| Change orders and their status | Approved contract value and billings | Change order impact on margin |
| RFIs, submittals, daily logs | Accounts payable and payroll | Whether a delay has cost yet |
| Progress and percent complete | Revenue recognition | Whether the job is over or under billed |
Why the integration estimate is always low
Projects to connect ProjectSight to an ERP tend to look like three months on the plan and land somewhere past a year. The estimate usually covers the integration. What it misses is the modeling.
Moving data between two systems is the tractable part. Getting cost-to-complete, change order impact, and budget variance to reconcile across both, so that a single number holds up under scrutiny from two departments, is where the timeline actually goes. It is worth walking through why each of those three is harder than it sounds.
- Cost to complete depends on a forecast that lives in the project system and an actual that lives in the ERP, measured on different cutoffs. Project teams forecast to the current state of the work. Finance posts to a period. The two agree only if somebody defines which wins at the boundary.
- Change order impact depends on status, and status is a spectrum. A change order can be identified, submitted, pending, approved, or executed, and different parts of the business treat different points as real. Reporting that does not encode which status counts will produce two defensible margins for the same job.
- Budget variance depends on the two systems sharing a cost breakdown. When the project budget is structured by scope and the ERP is structured by cost code, the variance is only as good as the mapping between them, and that mapping is usually undocumented.
None of that is exotic. It is just modeling work, and modeling work is what gets left out of an integration estimate.
What a shared foundation does for the project dashboard
The Foundation Pack brings both sides into one governed lakehouse on Databricks or Microsoft Fabric, with automated pipelines handling the movement and metric stores your team builds the reporting on. Cost-to-complete, change order impact, and budget variance end up running off the same data, so the number a PM manages to is the number finance reports.
Being clear about the boundary matters here as much as anywhere. The Foundation Pack delivers the pipelines, the governed lakehouse, the security model, and pre-built models for General Ledger, job cost, accounts payable, and payroll to build from. It does not deliver finished ProjectSight reporting on day one. What it removes is the year that a custom build usually spends on plumbing before anyone writes a useful measure.
Owners get a live Power BI dashboard instead of a PDF built at 11pm. And when the owner asks something the deck did not anticipate, the answer is a filter rather than a rebuild.
The risk argument underneath the cost one
A custom build carries key-person risk. When the one person who understood the model leaves, the model leaves with them, and what remains is a set of reports nobody will touch because nobody can prove what they do. A foundation deployed across more than 250 implementations does not have a single point of failure with a resignation letter attached.
That risk is not theoretical in the current market. KPMG’s 2025/2026 Global Construction Survey, drawing on 375 industry leaders, found 76% naming workforce as critical to their strategic priorities and 82% planning to increase investment in training (KPMG, 2026). Analytics knowledge that lives in one person’s head is exposed to exactly the talent pressure the industry is already worried about.
The same survey found 75% of executives reporting greater risk aversion than a year earlier. A reporting layer that only one person can maintain is a risk most contractors would not knowingly accept if it were written down as one.
A better question than how long the deck takes
Ask instead what happens when the owner asks a follow-up. If the answer is that someone goes back to the source systems and rebuilds, the reconciliation call is not a process. It is a symptom.
The second question is who else is waiting on the same answer. The reconciliation that produces the owner deck usually also produces the internal forecast, the WIP review, and the number the CFO takes to the board. When that work happens once, in a model, all four get the same answer without four rebuilds.
The Foundation Pack for ProjectSight is listed on the Trimble Marketplace, where you can see the full scope or start a conversation with our team. There is more detail on the Foundation Pack page.
See the Foundation Pack for ProjectSight
One governed lakehouse behind both the project data and the financial data, with metric stores your team builds the reporting on. See the full scope or reach our team through the listing.
Frequently Asked Questions
What is cost to complete in construction?
Cost to complete is the estimated remaining cost to finish a job, and it is the number that turns actual spend into a forecast. It is calculated as estimated total cost minus cost incurred to date, but the useful version is a considered forecast rather than arithmetic, because the remaining work rarely matches the original assumption. It matters because percent complete, earned revenue, and projected margin all depend on it, so an inaccurate cost to complete quietly moves every downstream number.
Why do change orders break project reporting?
Because a change order is not a single event. It moves through identification, submission, pending, approval, and execution, and different departments treat different points as real. Operations often forecasts against pending work because that is what the crew is doing. Finance recognizes at approval because that is what is contractually collectible. Both positions are defensible, so reporting that does not explicitly encode which status counts will produce two different margins for the same job and no way to tell which is right.
Can ProjectSight integrate with an ERP directly?
Data can be moved between them, and many contractors do exactly that. The limitation is that an integration synchronizes records, it does not agree on definitions. You can have budgets flowing correctly from one system to the other and still have two departments reporting different cost to complete, because the reconciliation problem is about meaning rather than transport. Analytics on a shared governed foundation solves a different problem than integration does, and most contractors eventually need both.
Does the Foundation Pack include pre-built ProjectSight reports?
No. The Foundation Pack delivers automated pipelines, a governed lakehouse on Databricks or Microsoft Fabric, the security and administration tooling, and metric stores, meaning pre-built models for General Ledger, job cost, accounts payable, and payroll. Your team builds the ProjectSight reporting on that base, or our team builds it with you. The value is that the infrastructure work, which is the part that usually consumes a year on a custom build, arrives already done.
How long does it take to get project and financial data into one place?
A Foundation Pack deployment runs 8 to 12 weeks to production across four phases: assessment and planning, foundation implementation covering pipelines, lakehouse and security, analytics development, then deployment and adoption. The variable is not the technology. It is how quickly your organization can settle the definitional questions, particularly which change order status counts and how percent complete is measured.
