Your schedule of values should be a translation of your estimate, not a new document. Subs who open a blank spreadsheet on Monday morning to "build the SOV" are doing the work twice — and losing two to four weeks of cash on the first pay app because the GC rejects what they submit.

The fix, in six steps:

1. Pull the estimate's cost codes.
2. Group them into 15 to 30 billable lines.
3. Allocate overhead and profit cleanly.
4. Set defensible mobilization and stored-materials lines.
5. Reconcile to the contract total.
6. Submit with a crosswalk.

The rest of this post is the method.

Why this matters

The schedule of values is the document your cash flow runs on for the life of the job. Every pay application is a percent-complete claim against the SOV's line items.

If the SOV is wrong — wrong structure, wrong granularity, wrong allocation, wrong total — every pay app inherits the problem. You spend the project arguing percent complete instead of getting paid for work installed.

There's also a structural problem most subs don't name out loud. The estimate and the SOV usually live in different systems, owned by different people, on different timelines:

• The estimator builds the bid.
• Someone in the office — controller, PM, owner's spouse, whoever has the spreadsheet — builds the SOV from scratch after the contract is signed.
• The two documents drift. Cost codes don't match. Totals don't reconcile.
• The GC project accountant kicks it back. Pay app one slips two weeks. Then four.

The fix is not a better spreadsheet template. The fix is to treat the SOV as a derived document — the estimate, restructured for billing.

What is a schedule of values?

A schedule of values is a line-item breakdown of your contract price. It lives on AIA Form G703 (or a GC's equivalent), which feeds the G702 pay-application cover sheet.

Each line has:

• A scheduled value
• Percent complete this period
• Work completed to date
• Stored materials
• Retainage
• Balance to finish

The line items are yours to define within whatever the contract requires. That definitional freedom is exactly where most subs trip.

The six-step method

Step 1 — Pull the estimate's cost codes

Open your estimating system. Export the cost-code structure and the dollar value rolled up to each code. Not the takeoff quantities. Not the labor hours. The cost codes and totals — that's the SOV's skeleton.

If your estimating system doesn't produce a clean export, that's a separate problem worth fixing this quarter. For now, work from whatever summary the estimator produced.

The point: start from the estimate, not from blank.

Step 2 — Group cost codes into billable line items

Cost codes are usually too granular for an SOV. An estimator might track 80 codes on a $2M scope. A G703 with 80 lines is a nightmare to bill against and a nightmare for the GC to approve.

Consolidate to a working range. For most subcontractor scopes between $500K and $5M, somewhere between 15 and 30 line items.

The grouping logic should match how the work installs and how it gets inspected. If the GC walks the site and signs off on "underground rough-in" as a single milestone, "underground rough-in" is one SOV line — not three.

Two failure modes to avoid:

• Too few lines. A six-line SOV on a $3M scope means every pay app turns into a percent-complete negotiation. The GC pushes you down. You don't have granular evidence to push back.
• Too many lines. Forty-plus lines means you spend a day every month updating percentages and chasing approvals on tiny dollar amounts.

Step 3 — Allocate overhead, profit, and bond

Three options, in order of GC acceptance:

1. Proportional distribution. Spread O&P and bond costs across all direct-cost lines as a percentage. Cleanest. Most GCs accept it without comment.
2. Named lines. Add explicit "General Conditions," "Overhead," "Bond," and "Profit" lines. Some GCs require this. Some prohibit it. Check the contract.
3. Hidden in mobilization. Don't. This is front-loading by another name, and project accountants flag it.

Pick the method the contract or GC standard requires. If neither specifies, default to proportional.

Step 4 — Set mobilization and stored-materials lines

Mobilization is legitimate. You have real costs in the first 30 days — bonds, insurance, submittals, shop drawings, initial deliveries, supervisor ramp-up. A reasonable mobilization line gets your first pay app off the ground and is broadly accepted.

The trap is front-loading: inflating mobilization, submittals, and early-trade lines beyond what they actually cost so you collect more cash early.

GCs and sureties read every SOV with this in mind. The consequences stack:

• The SOV gets rejected.
• You get tagged as a credit risk.
• On bonded jobs, it escalates to the surety.

That last consequence is the one most subs underestimate.

Reasonable mobilization for most subcontractor scopes runs in the low single-digit percent of contract value. If yours is higher, have a documented reason — equipment mobilization on a heavy-civil scope, long-lead procurement, a specific contractual milestone — and put that reason in the crosswalk you submit with the SOV.

Stored materials get their own treatment. If the contract allows billing for materials stored on-site or in a bonded warehouse, set up separate lines for major material packages so you can bill against them when delivered. Most contracts require proof of storage, insurance, and a bill of sale. Have that paperwork ready before pay app one.

Step 5 — Reconcile to the contract total

The SOV total must tie to the contract sum to the dollar. Not "close." To the dollar.

If you have $3,247,615 in the contract and $3,247,600 on the SOV, the GC project accountant rejects it on receipt. They are not going to find the $15 for you.

Most reconciliation failures come from rounding inside the line items. Carry cents at the line level if you have to. The total has to match exactly.

Step 6 — Submit with an estimate-to-SOV crosswalk

This is the step almost no one does, and it's the one that gets the SOV approved on the first pass.

The crosswalk is a one-page document — a table is fine — showing which cost codes from the estimate roll up into which SOV line items. The GC project accountant doesn't have to reverse-engineer your logic. They see line 12 on the SOV, look at the crosswalk, see the three cost codes that fed it, and approve.

A crosswalk turns the project accountant from a gatekeeper into a co-signer. It also gives you a defensible record if a line is challenged later in the job.

What this looks like in practice

A concrete example. Subcontractor: mechanical, $2.4M scope, GMP project, bonded.

The build:

• Estimator produces 47 cost codes across underground, equipment, distribution, controls, testing, and closeout.
• Controller groups to 22 SOV line items:
  • Underground: 3 lines (rough-in, backfill verification, hydro test)
  • Equipment: 6 lines, one per major package, plus a separate stored-materials line for the chiller and the air-handling units
  • Distribution: 5 lines by floor
  • Controls: 3 lines by system
  • Testing: 2 lines
  • Closeout: 3 lines (commissioning, O&M manuals, training)
• O&P and bond distributed proportionally across all 22 lines.
• Mobilization line at 2.4% of contract — bonds, insurance, submittals, supervisor ramp. Documented in the crosswalk.
• Two stored-materials lines for chiller and AHUs, $410K combined, with storage paperwork attached.
• SOV total ties to contract to the dollar.
• Crosswalk shows the 47 cost codes mapped to the 22 SOV lines.

The result:

Submitted Monday. Approved Wednesday. First pay app submitted the following Monday. Approved without revision.

That's the outcome. The work happened in steps one through six.

Frequently asked questions

No. The budget is your internal cost plan. The SOV is the external billing structure. They share a foundation — the estimate — but serve different audiences. Don't hand a GC your internal budget and call it an SOV.

Can we change the SOV mid-job?

Yes, with the GC's approval, usually via a change-order process or an SOV revision. Common reasons: scope changes, stored-materials additions, line-item splits when a single line becomes too coarse. Don't change the SOV silently; the project accountant will notice and the next pay app will stall.

What if the GC gives us their SOV template?

Use it. The principles in this post don't change — pull from the estimate, group thoughtfully, allocate O&P cleanly, reconcile, crosswalk — but the line-item structure follows the GC's template. The crosswalk becomes even more important in that case because you're mapping your cost codes into someone else's structure.

How does the SOV affect bonding?

Sureties review SOVs on bonded jobs and on contractors with active bond lines. A clean SOV that doesn't front-load supports a stronger bonding position. A pattern of front-loaded SOVs across multiple jobs gets noticed.

Where does Ask Bre™ fit?

Ask Bre™ is Breva's financial-coaching agent. It can talk you through the cash-flow implications of your SOV structure and help you read your Breva Score in light of pay-app cycle data. It does not build the SOV for you. The six steps above are still your work.

What to do this week

One specific thing you now know: an SOV built from a blank spreadsheet is the reason your first pay app slips. Two to four weeks of cash in the first 60 days of every job, traceable to one upstream document.

One specific thing you can do this week: pull your most recent estimate and the SOV that came out of it, and lay them side by side. If you can't produce a one-page crosswalk between the two in 30 minutes, you've found the source of your pay-app friction. Fix it on the next job.

See where your pay-app cycle actually stands

The SOV is upstream of the pay app. The pay app is upstream of cash.

If you don't know how your pay-app cycle compares to other subs in your trade and region, the Pay-App Benchmark gives you that read in about ten minutes — free, no sales call, your data stays yours.

See how your pay-app cycle compares →

Sources and references

• AIA Contract Documents — G702 Application and Certificate for Payment and G703 Continuation Sheet. The standard forms referenced throughout this post. (Editor: verify current AIA URL before publish.)
• Breva Pay-App Benchmark — proprietary data on subcontractor pay-app cycle times across trades and regions. benchmark.breva.ai

This post reflects general industry practice as of the date of publication. It is not financial, legal, accounting, or tax advice. Contract language, GC requirements, and surety standards vary by project — consult your contract, your accountant, and your bonding agent for decisions specific to your situation.

Breva® is a registered trademark of Cadence Financial Group, Inc. DBA Breva. Ask Bre™ and BuildForward™ are trademarks of Cadence Financial Group, Inc.