# Where a job loses money between the estimate and the invoice

> Most unprofitable jobs were priced correctly. They lost money in the undocumented changes, the hours nobody attributed, and the estimate that was never compared to what actually happened.

Canonical page: https://priv-life.com/blog/where-jobs-lose-money

Ask a contractor which jobs lost money and you get a confident answer. Ask why, and you get a theory. The difference between the theory and the truth is usually sitting in three places nobody looks.

## The estimate was probably fine

It is tempting to blame pricing. Usually pricing is not the problem — the same estimator, using the same rates, produced profitable jobs that quarter too. What separates them is what happened after the estimate was accepted.

Three leaks account for most of it, and all three are record-keeping failures rather than judgment failures.

## Leak one: the change that was agreed in the driveway

A client asks for something extra. It is small. The crew does it, because saying no to a small request is bad service and nobody wants to send paperwork over a light fixture.

Then it happens eleven more times.

None of the twelve was worth a change order on its own, which is exactly why none of them got one, and why the job came in four days late with materials nobody budgeted. At the end, the invoice either matches the original estimate — and the twelve favors are free — or it does not, and now you are explaining a surprise to a client who genuinely does not remember agreeing to any of it.

The fix is not stricter paperwork. It is cheaper paperwork: a change order that takes ninety seconds to raise and gives the client something to approve from their phone. The threshold for "worth documenting" needs to be lower than the threshold for "worth arguing about later," and it almost never is.

Two details matter more than they look. A change order has to carry its own price and its own schedule impact — "plus two days" is half the cost of most changes, and the half that gets omitted. And an approved change order has to move the contract value, not sit beside it in a folder. A change log that does not change the number it describes is a diary.

## Leak two: hours that landed nowhere

Most job-costing systems can tell you the total hours on a job. Far fewer can tell you which hours went to which part of it, which is the only version that teaches you anything.

If forty hours of finish carpentry were estimated and eighty-two were spent, that is a fact you can price against next time. If the job simply used 340 hours against an estimate of 280, all you know is that it ran over — and the natural response is to pad everything by twenty percent, which loses you the next bid.

The thing to watch for is unattributed time. Hours that cannot be matched to both a task and a role are not neutral; they quietly destroy the comparison. Worse, if you let them be guessed at — spread evenly, assigned to the nearest task, attributed to whoever was on site — you get a cost history that looks precise and is fiction. Count them, report them as unattributed, and fix the capture. A number you know is incomplete is more useful than one you wrongly trust.

## Leak three: nobody compared the estimate to the outcome

This is the expensive one, because it is the one that makes the first two permanent.

Jobs close. Invoices go out. The estimate that started it is three months old and lives in a different system, and the comparison that would turn this job into next year's better bid never happens. The organization keeps its pricing knowledge the way it kept its volunteer hours: in the heads of the two people who have been there longest.

A variance report is not a management ritual. It is the mechanism by which a business learns its own costs. Estimated versus actual, by task and by role, for every job that closes — and then the part almost nobody does: feeding that back into the template the next estimate starts from.

Done properly, that feedback has a shape worth being careful about. An average alone hides a trend: "suggested 40 hours, averaged over 7 projects, last 3 came in at 52" tells an estimator something that "average 44" does not. And learning must never quietly rewrite a live plan or an approved estimate — it changes the suggestion for next time, and that is all it should change. A system that edits yesterday's agreed numbers because it learned something today is not learning, it is losing your audit trail.

## The chain, not the documents

What ties this together is that an estimate, a proposal, a contract, a change order and an invoice are five views of one job, and most businesses keep them in five places. Every boundary between those places is a spot where a number gets re-typed, a change gets lost, or a comparison becomes impossible.

You do not need better documents. You need the estimate and the invoice to be the same object at different ages — so that "what did we quote, what changed, what did it cost, what did we bill" is one question with one answer, available before the next bid rather than after the year ends.

---

<div class="tryIt"><p><strong>Priv Life Projects</strong> runs the chain end to end — plan, estimate, proposal, contract, change orders, the resource grid, cost-to-complete and a variance report — and feeds what actually happened back into the template the next estimate starts from. <a href="/apps/projects">Explore Projects →</a></p></div>
