Schedule of Values Review: Catching Front-Loaded Pay Applications
Most conversations about overbilling in construction focus on the pay application — checking the math, reconciling stored materials, verifying percent complete. Those checks matter, but they catch overbilling after it is already structured into the project. The place overbilling actually begins is one document earlier: the schedule of values. The SOV is the breakdown that every monthly pay application bills against, and if it is built wrong, every pay application that follows is wrong in the same way.
A front-loaded schedule of values is one where the dollar values on early line items are inflated and later line items are correspondingly shaved, so the contractor draws cash faster than they earn it. The total still equals the contract sum — front-loading does not change what gets paid in the end, only when. But on a project that runs into trouble, when matters enormously. By the time you notice the pace, the SOV is approved and the structure is locked. The defense is to review the SOV before approving it, while you can still send it back. This post is about how.
A schedule of values is the agreed breakdown of a contract sum into individual line items, each with a dollar value, that together equal the total contract price. On an AIA-format project it lives on the G703 continuation sheet, the detail page that sits behind the G702 pay-application cover. A general contractor's SOV breaks the project into trades and phases — sitework, concrete, structural steel, framing, mechanical, electrical, finishes, general conditions. A subcontractor's SOV breaks their single trade scope into smaller components.
The SOV exists so the project can be billed by progress rather than all at once. Each month, the contractor reports a percent complete against each line item, and the pay application bills the dollar value that progress represents. That makes the SOV the billing backbone of the entire project — it is established once, near the start, and every pay application for the project's life bills against it. A line item set too high at the start stays too high for the duration. There is no monthly correction unless someone forces a formal revision.
Front-loading is the practice of assigning more dollar value to early-completing line items than those items actually cost, and pulling that value out of late-completing items. The contractor's real costs do not change. What changes is the timing of the cash.
A concrete example. Suppose mobilization and sitework genuinely cost $200,000, and finish work and closeout genuinely cost $200,000. An honest SOV lists each at $200,000. A front-loaded SOV lists mobilization and sitework at $340,000 and finishes and closeout at $60,000. The total is identical. But the contractor completes the front end early and bills $340,000 against work that cost $200,000 — collecting $140,000 of cash before earning it. The finish work, now carrying only $60,000 of billable value against $200,000 of real cost, is billed at a loss the contractor already pre-collected. It amounts to an interest-free loan from the owner, repaid by under-billing at the end.
Front-loading is not always done with bad intent. A contractor with thin working capital may front-load to fund the early cash demands of a project — payroll and materials come due long before the owner pays. But intent does not change the exposure the owner carries, and the AP team's job is to manage the exposure, not to read the contractor's mind.
Front-loading creates one core problem: at every point during the project, the owner has paid out more than the value of the work physically in place. The amount paid runs ahead of the work standing on the ground. As long as the project finishes normally, that gap closes at the end and nobody is harmed. The risk is everything that can happen before the end.
If the contractor defaults, is terminated, or walks off partway through, the owner is left holding the gap. They have paid for $340,000 of front-end work that cost $200,000, and now they must hire a replacement contractor to finish the back-end work — which the original SOV says is worth only $60,000 but actually costs $200,000. No replacement contractor finishes $200,000 of work for $60,000 of remaining contract value, so the owner pays the difference out of pocket. Front-loading silently converts a manageable default into an expensive one.
Retainage normally cushions this — money held back from each payment as security. But front-loading partially defeats retainage, because the over-collection on early line items can exceed the retainage held against them. The whole point of retainage is to keep the owner's exposure positive; a front-loaded SOV erodes that protection from the inside. That is why SOV review and retainage policy belong in the same conversation.
Front-loading shows up as a pattern across line items, not as one obviously wrong number. The reviewer compares the dollar weighting against what each scope realistically costs and looks for distortion concentrated in the items that finish first.
Red flags that signal a front-loaded schedule of values
- Mobilization billed well above a normal range — mobilization is typically a low single-digit percentage of contract value, not eight or ten percent
- General conditions or general requirements weighted unusually high, since those costs are spread across the whole project, not concentrated up front
- Early trades — sitework, foundations, structural — carrying dollar values that look rich relative to their share of total project cost
- Finish trades, closeout, punch list, and commissioning carrying values that look thin for the labor and material they require
- A large, vaguely labeled line item early in the schedule with no meaningful breakdown behind it
- Round numbers on major line items, suggesting allocation by judgment rather than by actual estimated cost
- Submittals, as-builts, O&M manuals, and warranty close-out items priced near zero, when those are real deliverables with real cost
- A line-item structure too coarse to verify — three or four giant lines instead of a breakdown granular enough to test
Any single flag may have an innocent explanation — a project genuinely can have heavy sitework. The signal is the combination: early items consistently rich and late items consistently thin. That pattern is front-loading, regardless of what each individual line is called.
Get AP insights in your inbox
A short monthly roundup of construction AP + accounting posts. No spam, ever.
No spam. Unsubscribe anytime.
The SOV is submitted once, near the start of the project, and it is approved before the first pay application. That submission moment is the entire window of leverage. Once the SOV is accepted and billing begins, changing it requires a formal revision the contractor has every reason to resist. Treat the first-time SOV review as a real gate, not a formality.
Review the schedule of values as carefully as you would review a pay application — because you are reviewing every future pay application at once. Compare the line-item weighting against the contractor's bid breakdown or your own cost estimate, push back on any line that looks rich relative to its scope, and require a breakdown granular enough to verify. The SOV is the one document where a few hours of scrutiny up front replaces months of monthly disputes. It is also the only point where you can change the structure before it is locked.
The most useful comparison is the SOV against the contractor's own bid or estimate, which shows what the contractor actually expected each scope to cost. If the SOV reallocates value away from that breakdown — pulling dollars toward the front — ask why. The second practical move is to require enough line-item granularity to test: an SOV with three lines cannot be reviewed, while one with thirty or forty lines reveals where the distortion sits. When a line looks front-loaded, ask for the cost backup. A contractor who can substantiate the number provides it; a contractor who is front-loading negotiates.
Front-loading is not the only way an SOV accelerates cash — stored materials is the other lever. When the SOV and pay application allow billing for materials delivered to the site but not yet installed, a contractor can order material early and bill it before it goes into the work. Used legitimately, stored-materials billing reflects real cost the contractor has incurred. Used as a cash device, an SOV structured to permit generous stored-materials billing becomes a second front-loading mechanism layered on top of the first.
Retainage interacts with both. Retainage is the percentage withheld from each payment — commonly 5 or 10 percent — held until completion as the owner's security. A correctly weighted SOV with appropriate retainage keeps the owner's exposure positive throughout the project: the value paid out, net of retainage, stays at or below the value in place. A front-loaded SOV pushes against that, and if the front-end over-collection outruns the retainage held, the owner's cushion is gone exactly when it would be needed. Reviewing the SOV weighting, the stored-materials terms, and the retainage rate together gives a complete picture of the owner's running exposure. Reviewing any one alone does not.
SOV review and pay-application review are not separate exercises — they are the same control at two points in time. The SOV review sets the structure; the monthly pay-app review confirms the contractor is billing honestly within that structure. Skipping the SOV review does not save work, it just moves the cost downstream into twelve months of pay-app friction over a structure that was wrong from the start.
Connecting SOV review to ongoing pay-app approval
- The approved SOV becomes the locked baseline; every pay application bills against it line by line
- Any change to a line-item value after approval requires a formal, documented SOV revision — never a quiet shift inside a pay application
- Each pay application's percent-complete claims get cross-checked against the project manager's progress reports for the same period
- If the SOV review surfaced front-loading that could not be corrected, the early pay applications on the suspect lines warrant tighter scrutiny
- The cumulative billed-to-date on every line stays at or below that line's scheduled value — billing over 100 percent on a line is an automatic flag
- Track running exposure: total paid net of retainage against total work verifiably in place
Carrying the approved SOV forward as the reference for every pay application is mechanical, repetitive work — checking each month's billing line by line against the baseline, watching for values that shift without a revision, summing billed-to-date against scheduled value on every line. It is exactly the cross-period reconciliation an AP automation platform like Covinly handles continuously: lock the SOV as the baseline, extract each pay application, flag any line where the scheduled value moved without a documented revision, and surface any line billing over 100 percent. The structure is enforced month after month, so the AP team's attention goes to the judgment call — whether the reported progress is real — rather than to re-checking arithmetic against last month's sheet.
Overbilling is structured into a project at the schedule-of-values stage, not at the pay-application stage — a front-loaded SOV weights early line items high so the contractor collects cash ahead of the work, leaving the owner over-paid relative to what is in place and exposed if the contractor walks. The SOV is submitted once and locked, so the first-time review is the only real window to fix the structure. Compare the line-item weighting against the contractor's bid, watch for early items rich and late items thin, demand granularity, and review the SOV, stored-materials terms, and retainage rate together. The pay-application checks still matter — but they verify honesty within a structure the SOV review is responsible for getting right.
Written by
Marcus Reyes
Construction Industry Lead
Spent twelve years running AP at a $120M general contractor before joining Covinly. Lives in the world of AIA G702/G703, retainage schedules, and lien waiver deadlines. Writes about the construction-specific workflows that generic AP tools get wrong.
View all posts