On a unit-price civil job, quantity is not a reporting detail. It is the product. You are selling linear feet, cubic yards, square yards, and each-counts. Everything the office does with the job is a transformation of the quantity number, which means an error there propagates into billing, cost, schedule, and the next bid.
The problem: quantities are counted twice, late, by different people
The standard process has quantities getting counted at least twice. Once informally by the crew, so they know where they are. Once formally near the end of the pay period, by a PM or engineer working from as-builts, station marks, and phone calls. The two counts rarely match, and the second one is authoritative because it is the one that gets billed.
What goes wrong:
- The count is a reconstruction. Somebody works backward from where the crew is standing to figure out what got installed and when, which loses the day-by-day detail entirely.
- Partial items are guessed. A structure that is set but not backfilled, or a run that is laid but not tested, gets an arbitrary percentage.
- Billing lags installation. Work that went in on the 3rd gets billed at the end of the following month because the count happened after the cutoff.
- Quantity and hours never line up. If the quantity is dated to the count and the hours are dated to the day, you cannot divide one by the other to get a production rate.
- Overruns surface too late. An item running long is discoverable within days if you are counting daily, and invisible for a month if you are not.
Quantity counted at the end of the month is a billing input. Quantity captured the day it goes in is a management tool. Same number, completely different value.
How PM Axsus handles it at the point of installation
Quantity capture in PM Axsus happens where the quantity is created: at the pipe, at the structure, at the lift. The crew logs what went in, against the pay item and cost code it belongs to, on the day it happened.
Three properties make that useful rather than merely tidy:
- It is dated to the work, not the count. The record carries the day the quantity was installed, which is what lets it pair with hours from that same day.
- It is attributed. The record shows who logged it, which matters both for accountability and for resolving questions months later.
- It is structured against your pay items. Quantities land against the schedule of values you actually bid, so no one has to map field descriptions onto pay items afterward.
From there the transformations are mechanical rather than interpretive. Earned value is the budgeted rate times the installed quantity. Percent complete is installed over planned. Production rate is quantity over the hours captured against the same code. None of those require a separate reporting cycle, because they are all views of one captured fact.
What the office sees
Pay applications with backup
Installed quantities by item and by date, so the pay app reflects work through the cutoff rather than through the count.
Items running long, early
Quantity against bid quantity, visible while there is still time to notify and negotiate.
Measured percent complete
Percent complete derived from counted work instead of estimated by the person with the most optimism.
The earned value input
Installed quantity is exactly what earned value is: budget times work actually performed.
There is a cash-flow argument here that owners of mid-sized contractors tend to appreciate more than PMs do. Billing what you installed, in the period you installed it, with backup attached, shortens the gap between spending money and collecting it. On a $20M-a-year contractor, moving a meaningful share of billing up by two to four weeks is a working-capital change, not a paperwork change.
Where this fits
Quantity tracking is the foundation under earned value management and production tracking, and it pairs with time tracking to make rates computable. For the underlying method applied to dirt, see earned value for dirt work.