Job cost is the beating heart of a construction business. Every margin decision, every bid, every projection traces back to the question: what did this job actually cost?
It is also one of the most reliably broken data sets in the industry.
This is not a technology problem. It is not a people problem. It is a structural problem that shows up in virtually every construction business once it passes a few million in annual revenue — and it gets worse as the company grows.
Why job cost data breaks down
There are five root causes we see again and again.
1. Coding inconsistency across teams and time
Job codes get entered differently depending on who is doing the entry, what division they are in, and when the entry was made. "Phase 3 — Framing" might appear as "03-FRAM", "3 Framing", "Framing P3", or just "3" depending on the person, the system, and whether the template was followed.
Over three years, a company with 50 active jobs might have 400 variants of 30 legitimate cost categories. Running a report that aggregates framing costs across jobs is meaningless — the data does not roll up cleanly.
2. Field activity does not match finance records
Field supervisors submit timesheets late, purchase orders get approved verbally and entered later, and materials are invoiced in the wrong period. The result: your current job cost report shows costs that belong to last month, and this month's numbers look artificially low until the batch catches up.
This is not fraud. It is normal operational lag. But if your finance team is making decisions based on job cost reports without understanding the lag, those decisions are based on stale data.
3. Change orders live in a different system than job costs
The change order is approved in field management software. It gets billed through accounts receivable. But the corresponding cost — the actual work done to complete that change — gets coded to the original budget line instead of the change order. The job appears over budget. It is not. The data just does not connect.
4. Subledger and GL do not agree
The job cost subledger tracks costs at the job/phase/cost-type level. The general ledger tracks costs by account code. In theory, they tie out. In practice, there are rounding differences, timing differences, and sometimes entries that hit the GL but never made it to the subledger — or vice versa.
If the GL and subledger do not agree, every job cost report is wrong by a calculable amount — but nobody knows which amount.
5. Multi-system environments compound everything
Most construction businesses above $10M run at least two systems: an ERP for financials and project management software for field operations. The integration between them is rarely perfect. Data syncs on a schedule, not in real time. Field entries may be mapped to different cost codes in each system. The reports in each system tell different stories about the same job.
What this costs you
The downstream effects are not abstract.
When job cost data is unreliable, bids are built on bad historical averages. Margins get estimated using the best-case version of what a job cost — not the true cost. Over time, bids get tighter because the historical data suggests the company is more efficient than it actually is.
Finance leadership loses confidence in the numbers. They stop trusting the WIP report. They run their own parallel spreadsheets. The month-end close takes longer because every number has to be manually validated before it can be signed off.
And when someone asks "how did we do on that job?" — the honest answer is that nobody knows. The data does not support a clean answer.
What good job cost data looks like
A job cost data set that is worth trusting has a few specific properties:
- Cost categories are defined, documented, and consistently applied across all jobs and all divisions
- Field entries link to job codes that exist in the financial system (no orphaned codes)
- Change orders have corresponding cost lines — revenue and cost move together
- The job cost subledger ties out to the GL at least monthly
- Historical data is consistent enough to support benchmarking across jobs of similar type and size
None of this requires a new software platform. It requires a cleanup of the existing data and a set of rules that govern how new entries get made.
The first step is understanding how bad it is
Most construction finance teams have a general sense that job cost data is messy. What they do not have is a quantified answer: which jobs are affected, which cost categories are unreliable, and what the magnitude of the discrepancies actually is.
That is the purpose of a data diagnostic. Not to blame anyone. Not to rip out the ERP. Just to get a clear picture of where the data breaks down so the right cleanup work can be scoped and prioritized.
A free Data Health Score is a fast first read. A Data Autopsy goes deeper — inspecting the GL/subledger tie-out, job code consistency, and field-to-finance linkages — and hands back a priority-ranked map of where the real problems are.
If your team is making margin decisions based on job cost reports, it is worth knowing whether those reports can actually be trusted.