The argument between project managers and finance over job cost is almost never about the numbers. It is about whose version counts. Vista stores construction cost across modules that were designed for different jobs, so two people can pull what looks like the same figure and get two answers, and neither of them is wrong.
Key Points: Vista Job Cost Reporting
- The disagreement is structural, not human. Vista holds cost in Job Cost, Project Management, AP, Payroll, and Service Management, and those modules have genuinely different structures. Reconciling them is modeling work, and most contractors do it in a meeting instead.
- Bad data is expensive at industry scale. Autodesk and FMI put the cost of bad data to global construction at $1.85 trillion in 2020, including $88.69 billion in rework, which was 14% of all rework that year (Autodesk and FMI, 2021).
- Construction math is the hard part. WIP, earned revenue, over and under billings, and fade and gain analysis are among the most complex calculations in any industry, and no generic BI tool ships them.
- User Defined fields defeat generic tools. UD fields are unique to every Vista implementation, so a model that does not decode them leaves your most contractor-specific data unreadable.
- A custom build is a 12 to 24 month project. The Vista Application Pack ships 11 construction perspectives and more than 2,000 pre-built measures instead, and deploys in 8 to 12 weeks alongside the Foundation Pack.
- The test is simple. If your PM and your controller cannot pull job cost independently and land on the same number, the reporting layer is doing a job the data model should be doing.
The job cost meeting nobody schedules but everyone attends
A PM pulls job cost from Vista and sees one figure. The controller pulls what looks like the same figure and sees another. They are reading different slices of a system that stores cost across modules built for different purposes, and the reconciliation happens in a meeting rather than in the data.
The meeting has a predictable shape. Someone exports to Excel. Someone else questions whether committed cost is in or out. A third person points out that the equipment charges posted after the cutoff. Forty minutes later the group agrees on a number that nobody can reproduce next month without repeating the same forty minutes.
That meeting is the symptom. The cause sits a layer down, and it is worth being precise about what it is, because the usual fix, another report, does not touch it.
Why Vista makes job cost reporting harder than it looks
Vista was built for construction project management and accounting, and it does that job well. It was not built for analytics. The gap shows up in five specific places, and any credible answer has to handle all five.
- Cost lives in five places with different shapes. Job Cost, Project Management, AP, Payroll, and Service Management each store cost according to what that module needs to do, not according to what a report needs to read.
- Construction calculations are genuinely difficult. WIP, earned revenue, over and under billings, and fade and gain analysis carry more conditional logic than almost anything in manufacturing or distribution reporting.
- User Defined fields are unique to your build. They hold the things your business actually manages by, and no generic model can decode them for you.
- Multiple calendars run at once. Fiscal, job costing, and payroll cycles overlap, so “this period” means three different date ranges depending on who is asking.
- The questions that matter cross module boundaries. Margin analysis needs AP, equipment, service, and job cost in one place, which is exactly the join a point solution avoids.
Any one of those is solvable. Solving all five from scratch is a twelve to twenty-four month project, and it overruns more often than anyone plans for.
What the assembly work actually costs
The industry research on this is not subtle. In a survey of nearly 600 construction leaders, PlanGrid and FMI found that respondents spend 35% of their time, more than 14 hours a week, on non-productive activities including looking for project information, resolving conflicts, and dealing with mistakes and rework. The same study put the cost of those activities to the US construction industry at more than $177 billion in labor in 2018, with miscommunication and poor project data accounting for 48% of all rework on US jobsites (PlanGrid and FMI, Construction Disconnected, 2018).
Autodesk and FMI later put a number on the data itself. Bad data, meaning data that is inaccurate, incomplete, inaccessible, inconsistent, or untimely, cost global construction an estimated $1.85 trillion in 2020. More than 30% of the 3,900 professionals they surveyed said more than half of their project data is bad, and only 12% said they always incorporate project data into their decision-making (Autodesk and FMI, Harnessing the Data Advantage in Construction, 2021).
None of that is a Vista problem specifically. It is what happens anywhere the reporting layer is asked to do modeling work. But it explains why the job cost meeting is so persistent: the assembly happens again every period, whether or not anything has changed.
What changes when every dashboard reads the same model
The fix is not another report. It is agreeing on the definitions once, in a governed model, so the number a PM manages to and the number finance reports come from the same place.
The Vista Application Pack does that with 11 pre-configured construction business perspectives, covering Accounts Payable, Accounts Receivable, Compliance, Equipment, Equipment Warranty, Equipment Work Order Detail, General Ledger, Job Cost, Procurement, Service Management, and Payroll Detail. Across those perspectives it ships more than 2,000 pre-built measures and construction KPIs and more than 1,800 business-friendly dimensions.
Four things in that model do the specific work the meeting is standing in for:
- WIP schedule logic ships already built, with earned revenue, over and under billings, and fade and gain analysis, rather than being assembled every period.
- Cost is joined across modules, so job cost, project management, AP, payroll, service management, and GL resolve against each other instead of being reconciled by hand.
- UD fields come through decoded with business-friendly names, which is exactly where generic BI tools give up.
- Row-level security mirrors Vista’s own access rules by company, job, and cost code, so nobody builds and reconciles a second permissions world.
Multi-calendar support handles the fiscal, job, and payroll cycles running at the same time, and multi-company and multi-currency consolidation covers the contractor who has grown by acquisition.
Build it yourself, or start from a model
| Custom build | Vista Application Pack | |
|---|---|---|
| Time to production | 12 to 24 months | 8 to 12 weeks with the Foundation Pack |
| WIP and earned revenue logic | Written and tested from scratch | Ships pre-built |
| UD fields | Mapped by hand, per implementation | Decoded automatically with business names |
| Ongoing ownership | Key-person risk on whoever built it | Maintained product, 250+ implementations behind it |
| Total cost of ownership | Baseline | 40% to 60% lower |
One construction customer identified $850K in cost saving opportunities across projects and a 28% improvement in project performance visibility within three weeks of implementation. Most of that was visibility they already owned and could not see.
The question worth asking your team
Not whether your reporting works. It probably works well enough. Ask whether your PMs and your controller can pull job cost independently and land on the same number, and how long the meeting takes when they do not.
Then ask a second one. When your CFO asks why margin on a job moved, does anyone answer from the model, or does someone go back to the source systems and rebuild? KPMG’s 2025/2026 Global Construction Survey found 75% of construction executives naming operational efficiency and profitability as a top strategic priority, and 68% ranking technology as critical to reaching it (KPMG, 2026). The gap between those two answers is where that priority either lands or does not.
If the answer involves a spreadsheet and a person who knows where the bodies are buried, the reporting layer is doing a job the data model should be doing.
The Vista Application Pack is listed on the Trimble Marketplace. You can see what it covers, or reach us directly through the listing. There is also a fuller breakdown on the Vista Pack page.
See the Vista Application Pack on Trimble Marketplace
Eleven construction business perspectives, more than 2,000 pre-built measures, and WIP logic that ships already built. See the full component list or reach our team through the listing.
Frequently Asked Questions
What is job costing in construction?
Job costing in construction is the practice of tracking every cost against the specific job that incurred it, rather than against the company as a whole. Labor, materials, equipment, subcontracts, and overhead are all coded to a job and usually to a cost code and cost type within it. Done well, job costing tells you the margin on a project while it is still running, which is the only point at which you can act on it. In Vista, the difficulty is that those cost types originate in different modules, so job costing accuracy depends on how well those modules are joined.
What is a WIP schedule?
A work-in-progress schedule is the report that reconciles what a contractor has earned on its open jobs against what it has billed. For each job it compares contract value, costs to date, estimated total costs, and billings to date, then derives percent complete, earned revenue, and whether the job is over or under billed. It is the central document in construction accounting, it is what sureties and lenders read first, and it is the report most often rebuilt by hand in Excel every month.
Why do project managers and finance report different job cost numbers in Vista?
Usually because they are reading different modules with different cutoffs and different definitions. A project manager tends to work from Job Cost and Project Management, where committed cost and forecast matter. A controller works from the General Ledger, where posted cost and period boundaries matter. Add payroll running on its own calendar and equipment charges that post on a lag, and the two views diverge without either being wrong. The fix is a governed model where the definition of a cost is agreed once and both roles read from it.
Can Power BI report on Vista without a pre-built model?
Yes, and plenty of contractors start there. Power BI will connect and produce useful single-module reports quickly. The work that does not come for free is the modeling: joining cost across Job Cost, Project Management, AP, Payroll, and Service Management, writing WIP and earned revenue logic, decoding User Defined fields, handling three overlapping calendars, and applying row-level security that matches what Vista already enforces. That modeling is the twelve to twenty-four months, not the connection.
How long does a Vista analytics deployment take?
Eight to twelve weeks to production for the Foundation Pack and Vista Application Pack together. The usual sequence starts with Finance, meaning General Ledger, Accounts Payable, and Accounts Receivable, plus Job Cost, then expands to Equipment, Service Management, and Payroll in later phases. Most organizations see something usable well before the end, as each data area becomes available for validation.
Do we need the Foundation Pack as well as the Vista Application Pack?
Yes. The Foundation Pack is the layer underneath: automated pipelines out of Vista, a governed lakehouse on Databricks or Microsoft Fabric, and the security and administration tooling around it. The Vista Application Pack is the construction semantic model that sits on top. The reason they are separate is that the foundation also carries your other systems, which is what makes consolidating a second ERP after an acquisition a matter of adding a model rather than building a second environment.
