Most project managers don't skip their cost-to-complete because they're careless. They skip it because the form feels risky, the number feels like a guess, and reaching it is one more login on a Tuesday afternoon. Four specific frictions account for almost every late or missing submission, and each one has a specific fix. Fix all four and the cost-to-complete that flows onto your WIP schedule every month arrives on time, without finance chasing anyone.
That estimate to complete (ETC, in finance's shorthand) is the one line on the WIP no system hands you. It only shows up when a PM turns it in. So this post is about the behavioral problem: getting the number submitted at all, on time. It is not what the number means or why a submitted number can still be wrong. It's why it doesn't arrive.
Why does submitting a cost-to-complete feel risky to a PM?
Submitting a cost-to-complete feels risky because a PM knows a number they type quickly today can be read back to them later. The fear, in the PM's own words, is a number used against them: "you said $340K in March, why is it $410K now?" When a form feels like it locks you into a figure you'll have to defend, the safest-feeling move is to wait until the picture is clearer. That's how a submission slides past the deadline.
The fix is to make the number revisable, not final. In WIP Ready, a submitted cost-to-complete stays editable until the controller closes the cycle, and a note field travels with it. So a March estimate that changes in April carries its own explanation ("picked up the added foundation work at Harbor Point Tower") instead of showing up as an unexplained swing.
A cost-to-complete a PM can revise until the cycle closes, with a note explaining why it moved, stops being a liability. It's a working estimate again, which is what it always was.
Why does entering a cost-to-complete feel like guessing?
Entering a cost-to-complete feels like guessing when the PM is asked for a number with nothing in front of them to check it against. No cost-to-date, no sense of how far along the job already is. A blank box reads as "invent a figure," not "confirm what you already know."
The fix is to put the reference data on the same screen. WIP Ready's submission form shows the PM their own project's current cost-to-date before they enter anything, so they can sanity-check the number against reality: "does $340K left sound right, given we've spent $360K of a $700K job?" That's a five-second gut check the PM can actually make, because the two numbers sit side by side. The app never calculates the cost-to-complete for them. The number stays the PM's call; it just gives them the context to trust their own answer.
A blank box produces a guess. Put the current cost-to-date next to it and you get a checked estimate instead.
Why aren't PMs told what finance does with the number every month?
Most PMs are never told what the number does after they submit it. It disappears into "finance's report," so there's no felt cost to being late — the only pressure is another email. When a task has no visible consequence, it loses to the twelve tasks that do.
The fix is context on the form itself, in plain language. WIP Ready asks the PM the question they actually think in ("how much more will it cost to finish Lincoln HS Renovation?"), not "enter your ETC." After they submit, a confirmation recaps what they entered and, in one line, notes that the number now feeds the report finance sends the bank and bonding company. The PM who wants the full picture can read the plain-English guide to cost-to-complete; the PM who just wants to submit and move on now knows their number matters.
The same cost-to-complete a PM treats as a formality is the input finance's percentage-of-completion math runs on every month. Show them that, once, on the form.
Why does the login and spreadsheet step kill submission rates?
The login is often the real reason a submission never happens. PMs don't have a Procore Marketplace seat for the finance-side tools, and they don't live in Excel. Ask them to log into a new system or fill out a spreadsheet and you've added the exact step that turns "I'll do it later" into "I forgot." This is independent of whether they know the number — they usually do.
The fix is to remove the login entirely. WIP Ready sends a mobile-first link by email, one per project, per cycle. The PM taps it, verifies with a one-time code sent to the email Procore already has on file, and lands on a single-screen form. No Procore seat, no spreadsheet, under two minutes from a job site. Compare that to the Procore Budget-tool steps, which still require a login and a calculation-method choice before you can type a number — exactly the friction this removes.
Even a vendor selling a different fix found the same effect. Hampton Enterprises' director of construction reported that project managers "started submitting their data on time" once a live cost-to-complete workflow removed the manual reporting friction, calling it a secondary effect of the easier process — part of a change that saved 24 to 32 hours a month across six PMs (Velixo case study).
| The PM's reason for delaying | The fix |
|---|---|
| Fear the number will be used against them later | Editable until the cycle closes, plus a note field that travels with the submission |
| The number feels like a guess with nothing to check it against | Current cost-to-date shown on the same screen before they submit |
| No visibility into why finance needs it every month | Plain-language framing ("how much more to finish?") and a confirmation showing where the number goes |
| Friction of a login or spreadsheet they don't otherwise use | A no-login, mobile-first link emailed per project, per cycle |
What does a late or skipped cost-to-complete actually do to your WIP report?
A late or missing ETC does more than delay a spreadsheet cell. It breaks the percentage-of-completion calculation the whole WIP report runs on. Under the cost-to-cost method, percent complete equals costs-to-date divided by the sum of costs-to-date and the ETC (Foundation Software). No current ETC, no denominator: the line is either wrong or can't be computed at all.
Here's the chain, link by link. First, stale POC%: the controller either carries last month's ETC forward unchanged (one of the most common sources of systematic WIP error) or leaves the job's percent-complete blank. Second, wrong earned revenue: a stale percent-complete produces a wrong earned-revenue figure for the period, over- or understating the job's recognized profit. Third, a WIP that can't close on time: one missing project holds up the entire monthly schedule, because a WIP is only as complete as its slowest job. Fourth, the controller chasing PMs at month-end: the last 48 hours of the close become a manual hunt for the two or three PMs who haven't responded, instead of a review of the numbers.
The one downstream signal of a chronically late or stale ETC is profit fade across successive WIP periods — which a surety underwriter reads as an estimating problem, not a process problem, by the time it surfaces (NASBP). A late ETC and a wrong ETC are different problems with the same symptom: the companion post on why a submitted number can still be wrong covers accuracy; this one covers arrival.
How do you fix PM submission compliance without more chasing?
The four fixes above aren't four separate tools. They're one submission flow. WIP Ready's PM submission link is that flow: an emailed, no-login, mobile-first link per project, per cycle. It shows the PM their current cost data, accepts a note, stays editable until the controller closes the cycle, and lands directly on the WIP schedule with a full record of who submitted what and when. The PM owns the number; the app just collects it the right way.
That's the honest answer to the adoption question a finance buyer actually asks: will my PMs really do this? They do it when submitting is easier than ignoring the email, and every design choice here is aimed at that. See exactly how the submission link fits into the full WIP workflow, from PM entry to the bonding-ready schedule, at wipready.com.
