Schedule of Values (SOV)

Definition — what it is

A Schedule of Values is a detailed statement that divides the total contract sum into discrete line items, each carrying a scheduled value, so that progress can be billed and certified against defined portions of the work. It is the pricing skeleton for every progress payment on a lump-sum or GMP contract, most commonly formatted as the AIA G703 continuation sheet that supports the G702 application. An SOV is not a cost estimate, a budget, or a cost code structure: an estimate predicts what the work will cost the contractor, while the SOV states what the owner will be billed for each portion of it, and the two rarely map one-to-one. When done well it is granular enough to bill accurately yet coarse enough to administer; when done poorly it becomes a vehicle for front-loading, disputes, and stalled payments.

Also known as: Schedule of Values, Cost Breakdown, Continuation Sheet (AIA G703), Billing Breakdown

Why it matters — what it protects

The SOV is the single instrument that makes progress billing possible on a fixed-price contract. Because the owner is not paying against actual costs, both sides need an agreed map of what each portion of the work is worth, so that partial completion can be translated into a dollar amount everyone accepts. Without a mutually agreed SOV there is no defensible basis for a payment application at all.

It governs cash flow for the entire project. How the contract sum is distributed across line items, and whether early activities like mobilization and submittals carry recoverable value, determines whether the contractor is cash-positive or financing the owner's project out of its own working capital. A poorly structured SOV can leave a contractor billing correctly yet chronically short of cash.

It is a primary defense against front-loading disputes. Owners and their lenders scrutinize the SOV precisely because contractors have an incentive to load value into early line items to accelerate cash collection. An SOV that assigns disproportionate value to mobilization or general conditions relative to installed work invites rejection by the architect, the owner's payment consultant, or the construction lender's inspector.

It is the evidentiary basis for percentage-of-completion revenue recognition and for any later dispute over what was paid for what. The line-item structure and the running percent-complete against each line become the record that auditors, sureties, and, in a claim, opposing counsel will read to determine whether billings tracked actual progress or ran ahead of it.

Lifecycle — how it moves

1. Development from the estimate

   The contractor translates the winning estimate into billable line items. This is a re-mapping, not a copy: estimate detail is reorganized into portions of work the owner will recognize and the architect can verify in the field.

2. Structuring and level of detail

   Line items are chosen to balance billing accuracy against administrative burden. Too coarse and the contractor cannot bill partial progress fairly; too fine and every application becomes an argument over small percentages.

3. Submission and negotiation

   The draft SOV is submitted to the architect and owner, usually before the first application. Reviewers test it for front-loading, for unbalanced general conditions, and for whether stored-materials and retainage handling are clear.

4. Approval and lock

   Once accepted, the SOV becomes the fixed template for every subsequent G702/G703. Values do not change casually; the total must always reconcile to the current contract sum.

5. Billing against it

   Each pay period, percent-complete is assessed per line, and the application computes work-completed-to-date, stored materials, retainage, and the current amount due. This is where accuracy of the underlying percentages is either disciplined or fictional.

6. Amendment by change order

   Approved change orders add, delete, or modify line items and adjust the total. Change work is typically shown as new lines so it can be tracked separately from base-contract progress.

7. Reconciliation at closeout

   As work finishes, every line drives to 100 percent, retainage is released, and the SOV total reconciles to the final adjusted contract sum. Lines that never reach 100 percent signal disputed or incomplete scope.

Anatomy — the data it carries

Line item number

Sequential identifier for each portion of work. Stable numbering matters because every application references the same lines over the project's life.

Description of work

The scope each line represents, often organized by CSI MasterFormat division or by building system. Vague descriptions are the root cause of billing disputes.

Scheduled value

The dollar amount allocated to the line. The sum of all scheduled values must equal the current contract sum, and imbalance here is where front-loading is detected.

Work completed from previous applications

Cumulative value billed and certified through the prior period. Carries forward unchanged and must reconcile to the last certified application.

Work completed this period

Value earned in the current billing period per line. The most scrutinized number, because it is the delta the owner is being asked to pay for now.

Materials presently stored

Value of materials delivered but not yet installed, billed separately and usually requiring proof of delivery, insurance, and off-site storage protections.

Total completed and stored to date

Cumulative earned value per line, the figure that drives the percent-complete and the retainage calculation.

Percent complete

Total-to-date divided by scheduled value. The field the architect certifies against site observation, and where optimism most often creeps in.

Balance to finish

Scheduled value less total-to-date. Reveals which portions of work remain and is a quick tell for lines billed ahead of reality.

Retainage per line

Amount withheld, typically 5 to 10 percent, sometimes varied by line so that fully complete portions can be released early.

Change order lines

Approved changes carried as distinct lines so the base contract and modifications remain separable for audit and cost tracking.

General conditions and mobilization lines

Time-based and setup costs. The most common front-loading target and therefore the most closely reviewed by owners and lenders.

Failure modes — how it breaks

Front-loaded line items

Value is shifted into early activities such as mobilization, submittals, and general conditions so the contractor collects cash faster than work is installed. It gets caught when the architect or lender's inspector compares billed percentages to visible progress, and it poisons trust for the rest of the job.

Too coarse to bill fairly

A line lumps together work that finishes at very different times, so the contractor cannot bill installed progress without either over-billing the incomplete portion or under-collecting on the complete one. Both create friction every single application.

SOV that does not reconcile to the contract sum

Change orders are executed but the SOV total is never updated, so the sum of scheduled values no longer equals the adjusted contract sum. Every application after that is arithmetically wrong and gets rejected.

Stored materials billed without protection

Materials are billed as stored without proof of delivery, off-site storage agreements, or insurance naming the owner. The owner pays for materials it has no security interest in, and if the vendor fails, the money is gone.

Percentages divorced from field reality

Percent-complete is estimated in the office to hit a cash target rather than assessed against installed work. Early over-billing must be given back later, producing an application where a line goes backward and inviting a dispute.

No separation of change work

Change order value is folded into base-contract lines instead of shown as new lines. The project loses the ability to trace what was paid for the base scope versus modifications, which is fatal in a later claim.

Metrics — how it is measured

Front-loading index

Ratio of billed percent-complete on setup and general-conditions lines to the project's overall percent-complete. A persistent gap signals cash acceleration ahead of installed work.

SOV-to-contract reconciliation

Whether the sum of scheduled values equals the current adjusted contract sum every period. A binary control that, when it fails, invalidates the application.

Line-item count relative to contract size

Granularity benchmark. Too few lines for the contract value predicts billing disputes; too many predicts administrative drag.

Retainage held versus contract terms

Cumulative retainage as a percentage of earned value, checked against the contract's retainage schedule and any early-release provisions.

Stored-materials share

Portion of the application represented by stored but uninstalled materials. A rising share warrants proof-of-storage scrutiny.

Percent-complete accuracy

Frequency of lines that decrease period-over-period, which indicates prior over-billing being corrected and undermines the credibility of the whole SOV.

The AI shift — what actually changes

Conversational

Instead of eyeballing a continuation sheet, you interrogate it: which lines are billed ahead of installed progress, whether the schedule of values still reconciles to the adjusted contract sum, how much of this period's request is stored materials, and where change work has quietly been folded into base lines. The answer comes back with the specific lines and figures that support it.

Generative

The first-draft SOV is built from the estimate rather than typed by hand. Given the winning estimate and the contract structure, a model proposes a line-item breakdown at a defensible level of detail, maps estimate scope to billable portions, and separates general conditions and mobilization so a reviewer edits allocations rather than assembling the sheet from nothing.

Orchestrated

The SOV stops being a standalone spreadsheet. It is tied to the schedule so percent-complete can be checked against activity progress, to executed change orders so the total always reconciles, and to the payment application so any period request is validated against the locked line values and retainage terms before it goes out.

Autonomous

Routine SOV maintenance runs continuously inside guardrails: reconciling the total to the current contract sum after every executed change, flagging lines billed ahead of schedule progress, checking stored-materials requests for supporting documentation, and preparing the continuation sheet for review. Humans still set the values, resolve front-loading questions, and approve every application.

Prompts — put it to work

Tool-agnostic and copy-ready. Adapt the specifics — thresholds, contract windows, cost codes — to your own project before you run them.

Conversational — Reviewing an incoming SOV for front-loading before you certify the first application.

Review this schedule of values against the estimate and contract sum. Identify any line billed or valued out of proportion to the work it represents, focusing on mobilization, general conditions, submittals, and any setup activity. Tell me the scheduled value and percent of contract for each of those lines, compare them to typical ranges for a project of this type and size, and flag anything that looks like value shifted forward to accelerate cash. Also confirm the sum of all scheduled values equals the current contract sum, and list any line whose description is too vague to certify against field observation.

What good output looks like: A short list of specific lines with their values and percentages, a clear front-loading assessment, and a confirmation that the total reconciles to the contract sum, not a generic explanation of what an SOV is.

Follow-ups:

• Which three lines would you push back on first, and what would you propose instead?
• Rebuild the general-conditions allocation so it recovers evenly over the schedule.
• What questions should I ask before accepting the stored-materials handling?

Generative — Turning a won estimate into a first-draft continuation sheet.

Build a first-draft schedule of values from this estimate for a GMP contract. Organize line items by CSI MasterFormat division, choose a level of detail appropriate for a contract of this size so each line can be billed on partial progress without lumping unrelated work together, and carry mobilization and general conditions as separate time-based lines valued for even recovery rather than front-loaded. Map each line back to the estimate scope it draws from, show scheduled values summing exactly to the contract sum, and include columns for retainage at the contract rate. Flag any estimate scope you could not cleanly assign to a billable line.

What good output looks like: A structured, MasterFormat-organized SOV whose values sum to the contract sum, with mobilization and general conditions separated and any unmapped scope explicitly flagged.

Follow-ups:

• Add distinct lines for the two approved change orders and adjust the total.
• Split the mechanical line so equipment, distribution, and controls bill separately.
• Produce the G703 continuation-sheet layout with the standard columns.

Orchestrated — A change order was just executed and the SOV needs to stay consistent everywhere it is used.

Change order 6 was executed today, adding scope and adjusting the contract sum. Update the schedule of values to reflect it: add the change work as new lines rather than folding it into base-contract lines, adjust the contract total, and confirm the sum of scheduled values equals the new adjusted contract sum. Then trace the impact: does the pending payment application need to be reissued, does the retainage calculation change, and are there schedule activities the new lines should map to so future percent-complete can be verified against progress. Tie each conclusion to the specific record that supports it and flag anything you are unsure about.

What good output looks like: An updated SOV that reconciles to the new contract sum with change work as separate lines, plus a cross-referenced impact summary covering the pending application, retainage, and schedule linkage.

Follow-ups:

• Draft the note to the architect explaining the SOV revision.
• Show me the before-and-after totals and the delta by division.
• Which future applications are affected by the retainage change?

Autonomous — Standing policy for keeping the SOV clean across the life of the project.

Maintain our schedule of values continuously under these rules. After every executed change order, add the change work as new lines, adjust the contract total, and verify the sum of scheduled values equals the adjusted contract sum; if it does not reconcile, stop and escalate to me with the discrepancy. Each billing period, compare billed percent-complete per line to the mapped schedule activity progress and flag any line billed ahead of installed work. Check every stored-materials request for proof of delivery, off-site storage agreement, and insurance naming the owner, and hold any request missing documentation. Never change a scheduled value, never certify a percent-complete, and never release retainage without my approval. Route every front-loading flag and every reconciliation failure to me with your reasoning.

What good output looks like: A maintained SOV that always reconciles, a short exception queue of front-loading and documentation flags, and a hard boundary that no value change, certification, or retainage release happens without a person.

Follow-ups:

• Show me everything you flagged and held this period and why.
• Which lines have you flagged as billed ahead more than once?

Get the full Construction AI Prompt Catalog — every prompt in the library in one document.

Maturity — locate yourself honestly

0. Level 0 — Spreadsheet in isolation

   The SOV lives in a standalone workbook rebuilt each project. It is disconnected from the estimate, the schedule, and the applications, and front-loading is caught only by whoever happens to notice.

1. Level 1 — Standardized template

   A consistent G703 template is used, values reconcile to the contract sum, and retainage is applied uniformly. Percent-complete is still estimated in the office without a check against the field.

2. Level 2 — Linked to schedule and changes

   SOV lines map to schedule activities and to executed change orders, so percent-complete can be tested against progress and the total stays reconciled automatically as changes execute.

3. Level 3 — Assisted drafting and review

   First drafts are generated from the estimate, front-loading and reconciliation checks run on every application, and stored-materials documentation is validated for human review.

4. Level 4 — Operated

   Reconciliation, front-loading detection, and stored-materials validation run unattended inside guardrails, while people own the values, the certifications, and every retainage release.

Common questions

What is the difference between a schedule of values and a budget?

The SOV is what the owner is billed for each portion of the work; the budget is what the contractor expects the work to cost internally. They are organized differently and rarely map line-for-line, because the SOV is a revenue and billing instrument while the budget is a cost-control instrument. Confusing the two leads contractors to bill against internal cost codes the owner never agreed to.

Why do owners care so much about front-loading?

Front-loading lets a contractor collect cash faster than it installs work, which shifts risk to the owner: if the contractor fails midway, the owner has paid more than the value in place and must complete the job with less money remaining than work remaining. That is why architects, owner's payment consultants, and construction lenders scrutinize early-activity line values before certifying the first application.

How detailed should an SOV be?

Detailed enough that partial progress on any distinct portion of work can be billed fairly, but coarse enough that each application does not become an argument over tiny percentages. A useful test is whether every line can be assessed against something observable in the field; if a line lumps together work that finishes at very different times, it usually needs to be split.

Can the schedule of values change after it is approved?

The line structure is meant to stay stable, but the SOV must change when the contract sum changes. Approved change orders add, delete, or modify lines, and the total is adjusted so the sum of scheduled values always equals the current adjusted contract sum. Changing values for any other reason, or failing to update after a change order, is a frequent source of rejected applications.