Every month you ask each project manager the same question — how much more will it cost to finish the job — and every month you build the WIP schedule on top of their answers. That estimate to complete (ETC) is the one number on the report no system hands you. It comes entirely from a PM's judgment, which makes cost-to-complete accuracy the hinge the whole construction WIP turns on. And four specific field conditions make a PM's ETC systematically too low: an unprocessed change order, a stale estimate-phase productivity rate, a crew shrunk by a delay, and field conditions that changed under a scope everyone still calls "locked."
When the ETC is wrong, the error does not stay in the field. It runs straight into your percentage-of-completion calculation, overstates earned revenue, and prints a gain on the WIP your surety underwriter reads as a healthy job — with no way to see the bad input underneath it.
This post is not what cost to complete means for a project manager; that ground is covered, and so is the difference between EAC and ETC. This is the next question: why the number is wrong four specific ways, and what each error does to the report you send the surety.
Why does one wrong ETC corrupt the entire WIP report?
One wrong ETC corrupts the entire WIP report because the cost-to-complete is buried in the denominator of every downstream figure. Under the cost-to-cost method, percent complete = costs to date ÷ EAC, where EAC = costs to date + ETC. So the ETC sets the EAC, the EAC sets percent complete, percent complete sets earned revenue, and earned revenue sets your over/under-billing position. Get the ETC wrong and you have not made one small error. You have moved every figure on the schedule at once.
This is not a niche method. Well over 90% of companies in construction use the percentage-of-completion method (Foundation Software), so for most general contractors this is the WIP, not one version of it. For the full derivation, see how ASC 606 percentage-of-completion is calculated.
Here is the same job line, two ways. Take Meridian Construction Group's Fairview Pavilion: a $5,500,000 contract with $3,000,000 in costs booked to date. The PM's correct ETC is $2,000,000. Now suppose the real remaining cost is $500,000 higher than the number the PM submitted. (Illustrative.)
| Line | Costs to date | ETC submitted | EAC | Percent complete | Earned revenue | Projected gross profit |
|---|---|---|---|---|---|---|
| ETC correct | $3,000,000 | $2,000,000 | $5,000,000 | 60.0% | $3,300,000 | $500,000 |
| ETC understated $500K | $3,000,000 | $1,500,000 | $4,500,000 | 66.7% | $3,666,667 | $1,000,000 |
A single $500,000 understatement in the ETC lifts percent complete from 60% to 66.7%, overstates cumulative earned revenue by about $367,000, and doubles the projected profit from $500,000 to $1,000,000. None of that reflects anything that happened on site.
Watch the over/under-billing column move with it. Say Fairview Pavilion has billed $3,500,000 to date. With the correct ETC, $3,300,000 of earned revenue leaves the job $200,000 overbilled — billings in excess of costs and estimated earnings, a liability finance expects to work off. With the understated ETC, $3,666,667 of earned revenue flips it to about $167,000 underbilled — costs and earnings in excess of billings. One wrong input moved the schedule's billing position across zero. (Illustrative.)
Note the direction on margin: an understated ETC almost never makes a job's profit look worse; it makes the margin look better — which is what makes it dangerous, because the error hides as good news. It does not hide everywhere, though. The same understatement swells the underbilling, and a growing underbilled position is its own flag an underwriter reads.
Why do unprocessed change orders make every ETC too low?
An unprocessed change order makes the ETC too low because the PM has taken on approved scope but has not yet loaded its cost into the cost-to-complete. The remaining work grew; the number on the WIP did not. This is the most common version of a stale ETC, and it is not a rounding error: on major projects, change orders account for 10–15% of total contract value, and some projects see change order costs reach 25% or more (Rhumbix).
The fallout chain is mechanical. The ETC is understated, so the EAC is too low, so percent complete is inflated, so earned revenue is overstated, so the WIP shows an apparent gain. The controller closes the schedule, the surety reads a healthier job than exists, and nobody touched a wrong cell. The wrong number arrived from the field as a "current" estimate.
What this looks like in the field: If a change order is approved but you haven't loaded it into your cost-to-complete yet, finance is reporting a number you didn't actually give them. The extra work is real cost — it belongs in your "how much more to finish" figure the moment the scope is yours, not after the paperwork catches up.
Why do estimate-phase productivity rates still drive the ETC months later?
Estimate-phase productivity rates keep driving the ETC months later because nothing replaces them unless the PM actively re-forecasts. The labor rates and crew-output assumptions baked into the original bid carry forward by default; if the field is running slower than the estimate assumed, the ETC keeps quoting bid-day productivity instead of what the job is actually achieving. The tool most PMs use does not correct this for them. Procore's Forecast to Complete defaults to Automatic Calculation: projected budget minus projected costs, a net-zero result with no human forecast in it at all unless someone manually overrides the line (Procore support).
So the fallout chain runs the same way as with a change order, just from a different cause: actual productivity is below estimate, but the ETC still reflects estimate-day rates, so the ETC is too low, the EAC is too low, percent complete is inflated, earned revenue is overstated, and the margin looks better than reality right up until the job closes and the real hours land.
What this looks like in the field: Your original bid assumed a crew hitting a certain output rate. If the field is running slower, your cost-to-complete needs to go up — and Procore won't do that for you automatically. Left alone, the system assumes you finish exactly on budget.
When the crew shrinks after a delay, why doesn't the ETC grow?
When the crew shrinks after a delay, the ETC should grow — but it usually doesn't, because the remaining-hours math never gets redone. A weather delay or a sub that doesn't show forces a smaller crew on return, which means more calendar time and often more total labor-hours to finish the same scope. Yet the ETC still reflects the original crew plan and the original hour count unless the PM formally updates it. The remaining labor cost is understated, so the ETC is too low, percent complete runs too high, earned revenue is overstated, and the WIP carries a phantom gain until someone re-forecasts.
For the controller, this error is invisible in the worst way: it looks identical to a stale-productivity error from the outside. The WIP shows the same inflated percent complete either way. You cannot tell from the schedule alone whether the cause was a slow crew or a shrunk one, only that the cost-to-complete is light. Both trace to the same place: an ETC that no one revised after the field changed.
What this looks like in the field: A two-week weather delay with a smaller crew on return means more hours to finish, not the same hours later. That needs to land in your cost-to-complete, not get absorbed silently and show up as an overrun at closeout.
If scope is "locked," why do field conditions still break the ETC?
Field conditions break the ETC even on a "locked" scope because the contract price staying fixed does not make the cost to finish stay fixed. Hitting rock where the bid assumed dirt, soft soil bearing that needs added support, buried utilities, or restricted site access all add real cost — and because the scope document is technically unchanged, the PM often never formally re-estimates. The contract says the price is set, so the cost-to-complete quietly drifts while the WIP keeps reporting the original assumptions.
This is the most dangerous of the four, because it stays invisible the longest. Silent cost growth means the ETC is understated for multiple WIP periods in a row, each one showing an inflated percent complete and a margin that holds. Then a late-period re-forecast finally catches up, the EAC jumps, and the schedule prints a dramatic profit fade in one cycle — which means every prior WIP the controller sent the surety was materially overstated, not just the last one. Some fade is normal; a sudden, large, late fade reads to an underwriter as an estimating problem.
What this looks like in the field: Hitting rock when you bid dirt is real money. If it changes what you need to spend to finish, it has to change your cost-to-complete — even if the scope document says the price is fixed. "Same scope" doesn't mean "same cost to finish."
What does each ETC error do to your WIP schedule? (one-table summary)
Each of the four errors does the same thing through a different door: it understates the estimate to complete (the ETC), which inflates percent complete, overstates earned revenue, and produces a gain on the WIP the surety cannot distinguish from a real one. The cause differs; the distortion is identical.
| Reason | What the PM submitted | POC% effect | WIP consequence | Surety reads |
|---|---|---|---|---|
| Unprocessed change order | ETC without approved scope added | Overstated (too high) | Earned revenue inflated; apparent gain on WIP | Healthier job than actual |
| Stale estimate-phase productivity rates | ETC based on original output assumptions | Overstated (too high) | Earned revenue inflated; phantom gain | Margin that may not materialize |
| Post-delay crew reduction not adjusted | ETC using original crew plan | Overstated (too high) | Remaining labor cost understated; gain inflates | Favorable WIP; execution risk invisible |
| Field conditions changed, no re-estimate | ETC assuming original site conditions | Overstated until late re-forecast | Silent cost growth; sudden late-period profit fade | Normal WIP — then abrupt fade |
Can a surety underwriter tell when the ETC is stale or wrong?
A surety underwriter cannot directly tell when the ETC is stale or wrong. The underwriter reads the WIP as a finished document: the estimate to complete arrives as one number in a table, with no audit trail of when it was last updated, who entered it, or whether it reflects the current state of the job. There is no field on a standard WIP that says "this estimate is three months old." The only visible signal is profit fade across successive WIP periods — and by the time fade shows, the damage to your bonding position is already done.
NASBP, writing from the surety's side, puts it plainly: "Profit fades occur when the actual costs of a project exceed initial estimates, eroding profitability" (NASBP). Some fade is normal. But a pattern of fade across multiple jobs reads to an underwriter as an estimating or project-management problem, and it directly lowers their confidence in your projected margins. The underwriter never sees the wrong ETC. They see its shadow, a quarter or two late, in the one column you most wanted to look clean.
How should the controller validate the PM's ETC before closing the WIP?
The controller validates the PM's ETC by checking that it is current, complete, and consistent with the objective cost data — before the schedule closes, not after the fade shows. Three checks catch most of the four errors above:
- Confirm the ETC was updated this cycle — that it was re-attested this month, not carried forward from last month's spreadsheet. A number nobody touched is the default failure mode.
- Reconcile the ETC against the Procore change-order register to catch approved scope that hasn't been loaded into the remaining cost yet — the unprocessed-change-order error.
- Compare the PM's assumed remaining cost against Procore's field-actuals to flag productivity divergence, so a job running slower than the bid shows up before closeout, not at it.
The problem is that all three checks depend on chasing the PM and cross-referencing systems by hand, every job, every month. That is where the time goes, and where stale numbers slip through. If you are doing the entry side of this in the budget tool today, our guides cover how to update cost to complete in Procore and which Procore Forecast to Complete method to use for each line.
WIP Ready closes the validation gap by changing how the ETC arrives in the first place. It enforces a monthly ETC submission deadline with automatic reminders, so the number is re-attested each cycle instead of carried forward. Every ETC comes in attributed to a named PM, timestamped, with a note explaining the assumptions ("includes $30K for the outstanding rock claim"), and the PM sees the current Procore cost-to-date as they enter it. It flags profit fade between closes, before the surety meeting rather than during it. WIP Ready never calculates the ETC — the number stays the PM's — it just collects it the right way and assembles the bonding-ready ASC 606 schedule from that attested number alongside Procore's objective data. That current, attributed forecast is what underpins WIP Ready's 45-minute monthly WIP close benchmark, set against the two-to-three-day manual rebuild it replaces. If you field that monthly request, see how the check-in works at wipready.com.
