Your estimate is your earliest budget

The most common cognitive error in trade contracting: treating the contract value as the project budget. The contract value is what someone owes you. The budget is what the work is supposed to cost. They are different numbers, set at different moments, by different people, for different reasons.

The estimate is the budget. It's set the day you submit the bid. Six weeks before NTP. Sometimes four months before NTP.

The two numbers and what each is for

Contract value — what the GC will pay.

Bid value + buyout savings + executed COs.
Used for: AR forecasting, billing, lien rights, cash management.
Set by: the GC's award letter and every subsequent CO.

Budget — what the work should cost you to deliver.

Estimated direct cost (L + M + S + E + O) plus a defined overhead allocation.
Used for: cost control, productivity tracking, EVM, job profitability.
Set by: the estimator on bid day. Locked at NTP. Not affected by buyout upside (that's profit, not budget).

Contract value − Budget = expected gross margin.

If you're using contract value as the budget, your gross margin is structurally zero at award — and any overrun goes straight to net loss with no buffer.

Why subs collapse them

Three reasons, mostly historical:

The estimator and the PM are different people in different systems. Estimator works in spreadsheets / dedicated estimating software. PM works in QuickBooks or Procore. The estimate doesn't travel — when the PM asks for a budget, they get the contract value because that's the number that's already in the project record.
"We bought it out for less than we estimated, so the budget is the buyout." Tempting and wrong. Buyout savings are margin recovery on the original budget, not a new floor. Resetting the budget to buyout costs makes any productivity slip eat directly into profit.
No central repository for the estimate. When the estimate exists as a workbook on the estimator's laptop, by month three of the project the PM is rebuilding it from contract docs to make a budget. By month six, they've given up and they're tracking against contract value.

What STrOp threads automatically

The single-pipeline value here is the part subs usually pay extra integrators to do:

Moment	Estimate becomes...
Bid submitted	Estimate is the priced proposal — the external number
Award + NTP issued	Estimate auto-locks. Becomes the internal baseline. Cost-code-level. Frozen.
Setup → SOV created	SOV groups the estimate into billable line items at contract-value rates; backing detail stays at baseline rates
Field work begins	Job-cost dashboard shows baseline (from estimate), forecast, actuals side-by-side per cost code
Procurement runs	Each PO ties back to its estimate line. Buyout variance is visible immediately, not at month-end
CO executes	CO carries its own mini-budget into the dashboard. Original baseline stays clean
Closeout	Final actuals roll up against original baseline. Lessons learned have a fixed comparison

You don't re-key the estimate. You don't rebuild it as a budget. The day NTP issues, the budget is already there — it's just the estimate with a different label.

What changes when you do it this way

Buyout savings are visible the day the PO posts. Estimated $80,000 for HVAC equipment, bought it at $74,000 — that $6,000 is margin recovery, not budget. The dashboard surfaces it as positive variance, not as a new budget floor.
Productivity drift catches a margin problem early. When labor cost per unit is 12% above baseline at week 4, you know the productivity assumption was wrong and you can re-staff, retrain, or reforecast. Without baseline, you have nothing to compare to.
CO pricing has a real basis. Pricing a PCO at "labor + 15%" without knowing your baseline labor cost is guessing. Pricing it from baseline rates gives you a defensible position.
Closeout produces actual lessons. Comparing final actuals to baseline (not to contract value) is how you learn that your conduit-in-slab assembly was priced 8% light three jobs in a row. That fix lives in the assembly library for bid #4.

The estimate-is-not-budget exception: the lump-sum CO

When a CO is executed for a lump sum (not detailed at line level), it adds to contract value without a matching baseline at cost-code level. STrOp lets you allocate the CO across cost codes manually (or use a default ratio) so the budget stays meaningful — otherwise the CO inflates contract value and the dashboard variance grows artificially.

Common failure modes

Updating the baseline when a CO executes. Don't. The CO carries its own budget. The original baseline stays static.
Treating buyout savings as new budget. A 7% buyout savings is a 7% margin lift, not 7% more room to overspend.
Re-pricing the baseline mid-project because "our prices are old." If you do this, all variance and EV data is invalidated. The right move is to forecast (current view) higher and leave baseline alone.
No baseline at all because the estimator and PM don't share a system. This is the gap STrOp closes. If you're outside STrOp and your estimator still works in spreadsheets, the highest-leverage fix is getting the bid file into the project record on award day.