A pay application is a claim, not a fact
An AIA G702 Application and Certificate for Payment states, for one billing period, how much of the contract has been completed, how much retainage is being withheld against that amount, and how much is due. The G703 Continuation Sheet behind it breaks that claim down line by line against the project's schedule of values — but neither form proves anything on its own. It's a claim the contractor is making, one that still needs to be checked against the contract that actually governs the project.
Checking it by hand means holding the current pay application, the prior period's pay application, the schedule of values and the contract's retainage terms side by side, and confirming that percent complete only moved forward, that retainage was withheld at the correct rate, and that the amount now due actually reconciles against everything billed to date. Most of the errors that matter hide in that cross-check, not in the arithmetic on any single form.
Why progress billing is harder to track than it looks
Retainage isn't a flat number
A contract can specify a flat retainage percentage, a rate that steps down once the project passes a defined completion threshold, or a rate that differs between the owner-to-GC contract and the GC-to-sub contract beneath it.
The schedule of values changes over the life of the project
Every approved change order adds, splits or revises a line item on the schedule of values, so the baseline a pay application is checked against is rarely the same document project to project — or even period to period on the same job.
Percent complete is a judgment call, not a measurement
The percent complete entered on a G703 line is an estimate from the contractor's project manager, not a metric read off an instrument — and it can move backward, plateau, or jump in ways that look like an error but reflect a real change on site.
Retainage held by the GC isn't the same as retainage held by the owner
A general contractor can withhold more retainage from a subcontractor than the owner withholds from the GC, and reconciling either side without keeping that distinction separate produces a number that doesn't belong to anyone.
None of these four are a contractor doing anything wrong — they're the normal shape progress billing actually takes on a real project. But they're exactly why comparing this month's pay application to last month's, by eye, rarely produces a confident answer about whether the numbers actually tie out.
What this doesn't do, stated up front
Doesn't judge percent complete
Percent complete on a schedule-of-values line comes from the contractor's own estimate. This checks that figure against the contract and prior periods for consistency — it doesn't send anyone to the site to verify it.
Doesn't generate G702/G703 forms
You keep preparing and submitting pay applications the way you already do. This reads the completed forms — it doesn't fill them out or replace the software you use to produce them.
Doesn't approve or certify a pay application
Certification is the architect's or owner's representative's role under the contract. This surfaces exactly what a certifier needs to see clearly — it doesn't make that decision.
Doesn't resolve a disputed change order
A change order pending approval, or a retainage dispute over a punch-list item, is flagged clearly enough to bring to the right conversation — resolving it stays a human decision.
What's left is narrow, and it's exactly the part that eats an afternoon every billing cycle: turning a pay application and a schedule of values into a confirmed answer about whether this month's claim actually ties to the contract.
What gets read
| Field | Source |
|---|---|
| Scheduled value and percent complete per line | G703 Continuation Sheet |
| Retainage withheld this period and to date | G702 / G703 |
| Current payment due and total earned to date | G702 |
| Change order amounts and status | Schedule of values / change order log |
| Deposit amount and date | Bank statement |
Five sources of truth, read as they actually exist — not summarized from memory, and not assumed to agree with each other until the matching step actually checks.
How a pay application is checked against the contract
The check runs on three things together, not any one alone, because any single check in isolation misses exactly the kind of error that matters most in progress billing.
| Check | Why it isn't enough alone |
|---|---|
| Line total against scheduled value | A line can be arithmetically correct in isolation while percent complete still moved backward from the prior period |
| Retainage rate applied | A stale rate applied after a contractual step-down still produces a number that looks internally consistent |
| Total to date against the contract sum | A running total can stay under the contract sum even while an individual line has been overbilled |
A pay application that passes all three — every line's percent complete moved only forward from the prior period, retainage was withheld at the currently correct contractual rate, and the running total stays within the contract sum including approved change orders — is confirmed with high confidence. A pay application that fails even one is exactly the case flagged for review rather than certified silently.
A pay application, reconciled
A $2.4M contract, month eight of construction, pay application #8 submitted against a 22-line schedule of values.
| Component | Amount |
|---|---|
| Total completed and stored to date | $1,680,000 |
| Less retainage (5%) | −$84,000 |
| Less total prior certificates for payment | −$1,428,000 |
| Current payment due | $168,000 |
The $168,000 figure on the G702, taken alone, tells a project manager nothing about whether it's actually correct. Checked against the 22-line schedule of values, one line — interior framing — showed percent complete jumping from 40% to 90% in a single period, well beyond what the site's actual progress supported that month. Flagged, confirmed with the project manager, and corrected to 65% before certification — a genuine overbilling caught before it reached the owner, not a rounding difference.
How it works
Upload the pay application and schedule of values
The current G702/G703, the prior period's pay application, and the contract's retainage terms.
Every line is read
Scheduled value, percent complete, retainage withheld and amount due, kept linked to the source document.
Checked against the contract and prior period
Percent complete, retainage rate and running total together, with a confidence level per line.
Export
Excel, CSV, JSON or schedule-of-values format, with confirmed, flagged and unmatched lines kept as separate, labeled groups.
When the retainage rate changes mid-project
Many state prompt-payment statutes, and many contracts independently of statute, reduce the retainage rate once a project passes a defined completion threshold — commonly a step-down from 10% to 5% once the project reaches 50% complete. Applied inconsistently, this looks exactly like a billing error: retainage withheld this period is suddenly lower than the rate applied every period before it.
The contract's stated retainage terms, including any step-down trigger, are read once and applied going forward from the period in which the trigger condition is actually met — so a legitimate rate reduction is confirmed as correct rather than flagged as a discrepancy every single period after it takes effect.
Change orders and the schedule of values
An approved change order changes the contract sum, and with it, the baseline every subsequent pay application is checked against. A change order that adds scope typically becomes a new line on the schedule of values; one that revises existing scope can split or adjust an existing line's value. Either way, the schedule of values a pay application is billed against is not a fixed document over the life of the project.
An executed change order is read as a revision to the schedule of values baseline, with its own scheduled value and retainage treatment tracked from the period it takes effect — not folded silently into the original line, and not treated as an unexplained increase in contract sum with no supporting document.
Running this across several projects at once
A general contractor with several active jobs at once faces this problem multiplied — each project has its own contract sum, its own schedule of values, its own retainage terms, and its own pay application schedule, with no single view showing all of them side by side.
Each project's pay applications are read and checked on their own contract terms, and the results roll up into one portfolio-level view — a running total of retainage held across every job, alongside the detail for any single project when it's needed, without collapsing the distinct contracts into one undifferentiated number.
What happens to a line that doesn't tie out
A schedule-of-values line whose percent complete, retainage or amount due doesn't reconcile against the prior period or the contract isn't silently accepted or hidden — it's kept as its own visible flag, with the amount, the line item and the specific discrepancy noted, so a project manager can look at it directly before certification.
In practice, flagged lines turn out to be one of a small number of things: a change order not yet reflected in the schedule of values, a retainage rate step-down applied at the wrong period, or occasionally a genuine overbilling. Each has a specific, quick resolution once it's visible instead of buried in a total that looked roughly right.
Final retainage and substantial completion
Retainage withheld across the life of a project is typically due for release at substantial completion, often subject to a punch list being completed and closed out first — and the amount due at that point is the sum of every retainage line withheld across every prior pay application, not a figure anyone calculates fresh at the end.
Tracking retainage as its own running total from the first pay application means the final release amount is already known well before substantial completion is declared — a confirmed number to reconcile against the closeout pay application, rather than a reconstruction project that starts only once the project is already finished.
Who this is for
General contractors billing owners
A pay application confirmed against the contract before it's submitted, not trusted on faith every month.
Project accountants and controllers
One consistent check applied across every active project, regardless of which project manager prepared the pay application.
Bookkeepers serving construction clients
The same reconciliation method applied whether a client runs one job or a dozen at once.
Subcontractors billing general contractors
The same checks applied upward, confirming what's billed to the GC matches the sub's own contract terms.
This isn't a construction ERP
Worth being precise about the boundary. This doesn't replace Procore, Sage 300 CRE, Viewpoint or whatever system your project management and job costing already runs on — there's no integration, no sync, no attempt to become the system of record for the project. You export the pay application and schedule of values you already have, and upload them here.
For contractors who already convert construction-specific bank statements — the kind covered in bank statement conversion for construction — this is the document-level counterpart to that: the pay application and contract terms themselves, checked before the deposit that follows is reconciled against the bank.
Moving from a spreadsheet SOV
Most project accountants who reach for this have been tracking the schedule of values in a spreadsheet for a while — updating percent complete by hand each period, checking retainage with a formula that was built once and hasn't been revisited since the last rate change. It works, in the sense that a wildly wrong pay application usually stands out, but it catches nothing subtle: a line that moved backward, a retainage rate applied one period too early or too late.
The transition doesn't require abandoning the spreadsheet on day one. A reasonable first step is running the automatic check alongside the existing spreadsheet for one billing cycle, comparing the two, and building confidence in where they agree and where the automatic check catches something the spreadsheet formula missed.
What tends to convince a skeptical controller isn't a claim about accuracy — it's seeing their own pay application and schedule of values produce a checked result that catches a line moving backward, the kind of thing a formula built for the common case never flags.
How often to reconcile
Matching your reconciliation cadence to the project's own billing cycle is the simplest rule that actually works — monthly for the standard AIA cycle most contracts follow, more often for a project on an accelerated schedule. Reconciling less often than pay applications are submitted means several periods pile up before anyone checks any of them against the contract.
For a contractor running multiple projects on staggered billing cycles, it's often simpler to batch the check on a fixed monthly rhythm rather than chasing each project's individual submission date — slightly less immediate on any single job, but far easier to actually sustain across a portfolio.
Starting with one project, not the whole portfolio
A contractor running several jobs at once can find the idea of checking every pay application on every project simultaneously daunting enough to never start. A more realistic path is beginning with the highest-value or longest-running project — the one whose schedule of values is already well maintained — and using that as a proof of concept before extending to the rest.
That first project answers the practical questions that matter before scaling up: how cleanly does the pay application actually check against the schedule of values, how much manual correction do flagged lines need, and how does the resulting check compare to whatever process existed before. Answers from one project transfer reasonably well to the others.
A project with a clean, well-documented schedule of values and few outstanding change orders is a natural first candidate — not because messier projects don't matter, but because starting with the straightforward case builds a working process before it has to handle a job with disputed retainage or a long change order history.
What accuracy actually looks like
A useful way to think about matching accuracy isn't a single percentage — it's the shape of the distribution across confidence levels. A project with a clean schedule of values and few change orders sees most lines confirm at high confidence, with only a small tail needing review. A project with a long change order history or a disputed retainage line sees a larger medium-confidence tail, which means more review time, not necessarily more errors.
That distinction matters because it's tempting to read a larger review queue as a sign the checking is working poorly, when it's often just an honest reflection of how complex the underlying project actually is. The alternative — a system that resolves every ambiguous line silently and reports everything confirmed — isn't more accurate, it's just hiding the uncertainty instead of surfacing it.
In practice, most projects with a well-maintained schedule of values and normal change order activity see somewhere between 85% and 95% of lines confirm at high confidence on a given pay application, with the rest split between a quick medium-confidence check and a small number of genuine discrepancies worth investigating individually.
Privacy
Uploads go over TLS, encrypted end to end.
Processing runs on EU-hosted infrastructure.
Original documents are deleted immediately after extraction.
Contract and project data are never used to train AI models.
Full details are on the security page.