Your BOQ and your ledger should be the same system
Most construction firms price a job in one file and account for it in another. Here is what that gap costs, and how to close it without changing how you estimate.
Ask a contractor what a project is worth and you get an answer in about four seconds. Ask what it has cost so far and the answer takes three days, two phone calls and a spreadsheet that only one person knows how to open.
That gap is not a discipline problem. It is a data problem. The BOQ lives in an estimating file, the costs live in an accounts file, and nothing joins them except a person, and that person is busy.
What the gap actually costs
The cost is not the reconciliation hours, although those add up. The cost is every decision you make in the weeks before the reconciliation lands.
- You keep buying at the old rate because nobody has told you the steel line is already 12 percent over.
- You bill a client for progress you cannot substantiate line by line, so the certificate gets queried and payment slips a month.
- You accept a variation verbally because the paperwork is somewhere else, and then you argue about it at final account.
- You find out a job lost money at handover, which is exactly when you can no longer do anything about it.
A number that arrives after the decision is not information. It is a receipt.
The join that fixes it
You do not need to change how you estimate. You need one identifier to survive the whole journey: the BOQ line item code.
- 1
Import the BOQ as structured data
Not as a PDF, not as an attachment. Every line keeps its code, description, unit, quantity and rate as separate fields, so software can add them up and compare them later.
- 2
Post every cost against a line
A material delivery, a labour day, a subcontractor certificate: each one carries the BOQ code it belongs to. This is the only new habit the site team has to learn.
- 3
Let the rollup happen automatically
Section totals, project totals, committed versus spent, all derived. Nobody types a summary figure, so nobody can mistype one.
- 4
Read variance the same day
Budget vs actual per line, per section, per project. The report is a view of the data, not a monthly assembly job.
What becomes easy once the chain holds
| Job | Before | After |
|---|---|---|
| Monthly valuation | Rebuild the measure sheet from site notes | Progress already recorded per line, certificate prints from it |
| Cost control | Whole-project margin, once, at the end | Per-line variance, live, while you can still act |
| Variation claims | Argue from memory and a chat thread | The revision is dated, priced and attached to the original line |
| Cash forecast | Bank balance plus optimism | Committed costs and certified income with real dates |
None of this requires a bigger estimating team. It requires that the estimate stops being a document and starts being a record.
The objection worth taking seriously
Site teams will not code every cost if coding is painful. That is a fair objection and it is where most ERP rollouts die. The practical answer is to make the common case one tap: the supervisor opens the project, opens the line they are working on, and logs against it. If the field app makes people navigate a chart of accounts, the data will be wrong within a fortnight.
Pilot on one live project, not the whole portfolio. One project, one month, and compare the variance report against what your finance lead worked out by hand. If they match, the chain holds and you can roll it out with evidence rather than a mandate.
Where to start this week
- 1Take the BOQ of the project you are most worried about and get it in as structured lines.
- 2Turn on cost coding for that project only, for labour and materials.
- 3Run the budget vs actual report at the end of the month and compare it to your manual number.
- 4Fix the difference. It is almost always an uncoded cost, and finding it is the point.
Questions this raises
Do we have to re-estimate our current projects?+
No. Import the BOQ you already priced. The line codes and rates come across as they are, and cost coding starts from the day you switch on, not retroactively.
What if our BOQ format is not standard?+
Most firms have their own column layout. The import maps your columns to fields once, and remembers the mapping for the next project.