A plain-English walkthrough of the SOV: what it is, how it drives the G703 continuation sheet and progress billing, why front-loading is common and risky, how change orders append lines, and a full worked example with one month’s billing.
A schedule of values (SOV) is the line-item breakdown of a construction contract price, agreed with the owner or general contractor before billing starts, that assigns a dollar value to each portion of the work. Every month, you bill by reporting how complete each line is, and the SOV is the yardstick those percentages run against. It is the backbone of progress billing on commercial work: the contract says what the whole job is worth, and the SOV says what each piece of it is worth.
The SOV usually gets submitted shortly after contract award, alongside or as part of your first pay application, and once the owner or GC approves it, it is fixed. From then on, every pay application walks the same list of lines in the same order. That is why it deserves more thought than it usually gets: a well-built SOV makes billing fast and disputes rare, while a sloppy one haunts you every month until closeout.
Two audiences read it. The owner’s side (owner, architect, lender) uses the SOV to check that what you are billing matches what is actually built, line by line, before certifying payment. You use it to get paid for work as you perform it instead of floating the whole job on your own cash. Both of those work better when the lines match how the job actually gets built.
On AIA-style billing, the SOV literally becomes the rows of the G703. Each month you fill in the same grid.
On projects billed with AIA-style forms, the pay application is a two-part document: the G702 Application and Certificate for Payment (the summary page with totals, retainage, and signatures) and the G703 Continuation Sheet (the detail grid). The G703’s rows are your SOV lines, one for one, and its columns walk each line through the billing math:
The G702 then rolls the G703’s totals into one payment request: total completed and stored, less retainage, less what was certified on previous applications, equals current payment due. The mechanics are covered in depth in our AIA pay applications guide; the point here is that the SOV is not paperwork adjacent to billing — it is the billing structure. Get the lines right and every month afterward is filling in two columns.
Follow a commercial re-roof contract from SOV to a single pay application.
Say you sign a $500,000 contract for a commercial re-roof and submit this SOV:
The lines total exactly $500,000 — they must, or the SOV goes back for correction. Now bill month two, with 10% retainage. Application #1 billed mobilization complete ($25,000) and half the tear-off ($30,000), so previous applications = $55,000. This month the crew finished more tear-off, started deck repair, and got insulation and membrane moving:
So this period = $89,000, and total completed to date = $55,000 + $89,000 = $144,000, which is 28.8% of the contract. Retainage held is 10% × $144,000 = $14,400. Application #1’s certificate was $55,000 − $5,500 retainage = $49,500. So this month’s current payment due = $144,000 − $14,400 − $49,500 = $80,100. Every one of those numbers traces back to an SOV line and a percent complete someone can walk the roof and check — which is exactly why the format works. (If material had landed on site but not gone down yet, the stored materials column enters the math too — see our stored materials guide.)
Front-loading means weighting the SOV so early-schedule lines carry more than their true cost — a fat mobilization line, a rich tear-off number — so your first applications bill more dollars for the same physical progress. It is one of the oldest moves in construction billing, and the motive is legitimate: retainage and payment lag mean contractors finance the front of every job, and front-loading claws some of that cash back early.
It is also risky, in three ways. First, owners and architects know the move and review SOVs against cost expectations; an obviously padded mobilization line gets kicked back, and you start the relationship negotiating your own credibility. Second, front-loading is deliberate overbilling: cash arrives early, but the margin on the back half of the job is thinner than the billings suggest, and if costs run over on the finish work there is nothing left in the late lines to cover it. Your WIP schedule will show it as billings in excess — a liability — and your surety will read it exactly that way. Third, if the job terminates early or the owner has payment trouble, an accurate SOV protects you; a front-loaded one gives the other side an argument that you have already been overpaid for the work in place.
A modest, defensible weighting toward real early costs — actual mobilization, bonds and insurance, submittals and engineering — is normal and survives review. Fiction does not. The better answer to the cash-flow problem is billing on time every month, billing stored materials where the contract allows, and negotiating retainage terms — not disguising the numbers.
The SOV is fixed, but the contract is not. When a change order is approved, it does not smear across the existing lines — it is appended as its own new line (or lines) at the bottom of the SOV, with its own scheduled value. The G703 total then equals the original contract sum plus approved change orders, which is the revised contract value, and that is the number all future percentages and totals run against.
Keeping each change order as its own line matters more than it looks. It keeps an audit trail — anyone can reconcile the SOV bottom line to the original contract plus the change order log. It lets you bill change order work by its own percent complete instead of arguing about how it blends into a base line. And it protects the base lines’ history: the earlier applications’ math still stands, untouched.
Two rules keep this clean. Only approved change orders belong on the SOV — pending and verbal changes are not contract yet, and billing them invites rejection of the whole application. And never delete or reorder SOV lines, even ones that end up unused: prior applications reference the lines by position, and restructuring the sheet mid-job corrupts the reconciliation between every application before and after.
The order you actually do it in, before the first pay application goes out.
Your estimate already breaks the job into scopes with costs. Group those into billing lines, apply margin, and you have an SOV that reflects how the money is actually spent — which is the version that survives owner review and keeps your billings honest against cost.
A line should be something that progresses and finishes as a unit — tear-off, insulation, membrane, edge metal — so percent complete is observable from the roof. One giant “roofing system” line makes every month’s percentage an argument; separate lines make it arithmetic.
If the job has multiple buildings, phases, or mobilizations, split them into their own lines. When building B starts three months after building A, a combined line either underbills A or overbills B; separate lines just bill what happened.
Mobilization, bonds and insurance, submittals, closeout, and warranty documents are real scope with real cost. Listing them separately gets them paid when they occur — early ones early, closeout at the end — without padding the trade lines to compensate.
The lines must sum exactly to the contract amount. Aim for enough lines that progress is verifiable but few enough that the sheet is manageable — for most specialty-trade contracts that is roughly 8 to 25 lines. Get written approval before Application #1; a disputed SOV stalls every application behind it.
Append a line for each approved change order, keep the change order log reconciled to the SOV total, and never restructure existing lines mid-job. The SOV you close out with should read as the SOV you opened with, plus the documented history of every change.
Most SOV pain traces back to the same handful of choices made in week one.
A mobilization line nobody believes gets the whole SOV kicked back, slows your first payment, and sets up an overbilled back half of the job. Weight lines to real cost plus margin, and fix cash flow with billing discipline instead.
One “roof system — $400,000” line turns every application into a negotiation about what percent done the roof is. Lines that match observable scopes make percent complete something both sides can see instead of debate.
Folding an approved CO into an existing line destroys the reconciliation to the original contract and makes the CO’s own progress unbillable on its own terms. Append each approved change order as its own line, always.
When billing lines and cost codes carve the job differently, comparing billed to cost per scope means a mapping exercise every month. Build the SOV from the estimate so billing, budget, and job cost describe the same pieces of work.
Retainage is withheld from each application and released late — on a 10% job, that is $50,000 of a $500,000 contract you finance until closeout. Price the job knowing it, and track what is held so release billing does not get forgotten.
Lines that do not sum to the contract, a previous-applications column that does not match last month’s total, percent complete inconsistent with the dollars — any of these gets an application rejected and payment restarted on the review clock. The arithmetic must be exact every month.
Everything above is structure and arithmetic, and both are exactly what a hand-built spreadsheet slowly gets wrong: a previous-applications column keyed from last month’s file, a change order appended in one place but not the other, retainage recomputed slightly differently in month five, a G703 that no longer ties to the G702. None of it is hard; all of it has to be exact, every month, for the life of the job.
This is a place software genuinely earns its keep. In SitewideOps, the SOV lives on the project, and AIA-style G702/G703 pay applications are computed from it — previous applications, this period, stored materials, retainage held and released, current payment due — with each month’s application building on the last instead of being retyped from it. Approved change orders roll the revised contract and append their own SOV lines automatically, so the sheet stays reconciled by construction rather than by discipline. And because billing and job costing share the same project, the billed-versus-earned comparison your WIP schedule depends on is already there. If you want to see it against your own numbers, a free 21-day demo account takes a few minutes to set up.
See how SitewideOps computes G702/G703 pay applications straight from your schedule of values — retainage, stored materials, and change orders included.
Anyone interested gets a free 21-day demo account: the full product, every feature, no credit card.