Retainage is a running balance, not a line item
Once a single pay application is checked — retainage withheld this period looks correct — the actual question is rarely about that one period. It's about the running total: how much retainage sits withheld across every pay application submitted so far, whether the rate applied has stayed consistent with the contract, and what figure is actually due when a release finally happens.
This page describes exactly that mechanic — the logic that sits underneath progress billing and retainage, spelled out here in detail because it's worth understanding fully before trusting it with a real retainage balance.
Why retainage is easy to lose track of
In the simplest case, a flat retainage rate applies from the first pay application to the last, and the running total is nothing more than a sum. That case doesn't need much sophistication. What makes retainage genuinely hard to track is everything that deviates from that ideal.
A rate step-down triggered at 50% complete, a change order that adds a line with its own retainage treatment, a subcontractor whose retainage is held at a different rate than the GC's own contract with the owner — none of these are exotic edge cases. They're the ordinary shape retainage takes on projects that run longer than a few months or involve more than a single tier of contract.
What gets read
| Field | Where it's checked |
|---|---|
| Retainage withheld this period | Read exactly as it appears on the current G702/G703 |
| Cumulative retainage withheld to date | Compared against the running balance built from every prior period |
| Contractual retainage rate and any step-down trigger | Read from the contract and applied to the correct periods |
| Schedule-of-values lines and their status | Read from the current period, matched against prior periods as candidates |
How the running balance is built
Rather than treating each pay application as an isolated document, retainage is tracked as a chain — each period's figure checked against the balance every prior period has already established, so an error doesn't just affect the current period, it's caught against the full history.
Retainage withheld matches the currently correct contract rate
Checked against the running balance's most recent confirmed rate, including any step-down already in effect.
Retainage withheld matches the rate, but the running total looks off by a small, explainable amount
Flagged for a quick confirmation — often a rounding difference across many periods, not a genuine error.
Retainage doesn't match the running balance's expected rate
Flagged with the specific discrepancy shown — a step-down applied at the wrong period, most commonly.
No prior balance exists yet
The first pay application on a project establishes the balance from the contract's stated terms, not assumed from a default rate.
Each pay application is checked against its own real predecessor, not against an idealized template — the running balance reflects what actually happened on this specific project, step-downs and change orders included.
Rate step-downs and reduced retainage
A contract that specifies a retainage step-down — commonly from 10% to 5% once the project reaches a stated completion threshold — creates a running balance with two distinct phases, not one continuous rate. Applied inconsistently, the transition between the two phases looks exactly like an error: retainage withheld drops suddenly, with no obvious explanation on the pay application itself.
The step-down trigger is read once from the contract and checked against the project's actual progress, so the transition is confirmed as correct at the period it occurs — and every period after it is checked against the new, reduced rate rather than the original one.
Three confidence levels
Not every retainage figure is equally certain, and treating them all the same — either all trusted or all reviewed — wastes effort in one direction or risks silent errors in the other. Three levels keep that distinction visible.
| Level | When |
|---|---|
| High | Retainage rate matches the running balance's expected rate and the running total ties exactly |
| Medium | A small, explainable variance — typically rounding across many periods — with the rate itself correct |
| Low / flagged | The rate or running total doesn't match what the contract and prior periods together predict |
When a retainage figure doesn't tie out
A retainage figure that doesn't match the running balance isn't silently corrected to what was expected — forcing a number to match would be worse than leaving the discrepancy visible, because it would paper over an actual error in the contract terms, the pay application, or the running balance itself.
Instead it stays flagged, with the expected figure and the actual figure shown side by side, so a project accountant can decide what happened — a step-down applied a period too early, a change order not yet reflected, or occasionally a genuine mistake on the pay application.
Why a consistent schedule of values helps
A schedule of values that keeps the same line numbering and descriptions from the first pay application to the last does most of the tracking work before the running balance is even built. Small, consistent structure — even if it doesn't match any particular software's default template — tracks far more reliably than a schedule of values that gets reorganized or renumbered partway through a project.
For a project whose retainage consistently lands flagged for review, a short conversation about keeping schedule-of-values line numbering stable across pay applications is often more effective than any change on the reading side — the cleanest fix for a tracking problem usually lives at the source, not downstream of it.
How it works
Upload the pay application and the contract's retainage terms
Whatever the current G702/G703 shows, plus your project's retainage clause and any step-down trigger.
The current period is read
Retainage withheld, cumulative to date, and every schedule-of-values line's status.
The running balance check runs
Rate, cumulative total and step-down status checked together against the project's full history.
Export
Excel, CSV, JSON or schedule-of-values format, with the running balance and confidence level per line.
Retainage held by the GC vs. retainage held from the sub
An owner withholds retainage from a general contractor under one contract, and the GC withholds retainage from each subcontractor under a separate contract beneath it — and the two rates are not always the same. A GC can withhold 10% from a sub while the owner withholds only 5% from the GC, holding the difference as a cushion the GC's own contract entitles it to.
Each side of that relationship is tracked as its own running balance, tied to its own contract — the GC's retainage held from the owner and the retainage the GC holds from each individual sub never get collapsed into one undifferentiated total, because they belong to different agreements with different terms.
When retainage is reduced or waived by bond
Some contracts allow a contractor to post a retainage bond in exchange for a reduced retainage rate, or in some jurisdictions a waiver of retainage entirely — the surety, not the withheld cash, becomes the owner's security. Where this applies, the running balance reflects the bonded terms rather than the contract's default retainage rate, so a bonded project isn't flagged as underwithholding when it's actually following its own valid arrangement.
The bond itself — its amount, its terms, whether it covers the full contract sum or a partial amount — is read alongside the pay applications when provided, so the reduced or waived retainage is confirmed against a real document rather than taken on the contractor's word alone.
What accuracy actually looks like
The tracking accuracy is best understood not as a single percentage but as a distribution across the three confidence levels. A project with a stable schedule of values and a simple flat retainage rate sees most periods land at high confidence; a project with a step-down, several change orders, or a mixed GC/sub retainage structure sees a larger medium-confidence tail — more review time, not necessarily more errors.
That distinction is worth holding onto, because a larger review queue is easy to misread as a sign the tracking is unreliable, when it's often just an honest reflection of how genuinely complex the underlying retainage structure is. A system that resolved every ambiguous case silently wouldn't be more accurate — it would just be hiding exactly the uncertainty a project accountant needs to see.
How the running balance gets more reliable over time
The first pay application on a new project rarely produces the cleanest running balance — there's no history yet to check against. Two things improve it quickly after that: a schedule of values that stays consistent period to period, and change orders logged promptly rather than reflected weeks after they're actually executed.
Neither improvement requires a change to the tracking logic itself — they're improvements to the inputs the tracking works from, and that's usually where the effort pays off most when the running balance looks less reliable than expected.
What you get back
One running balance per project
Cumulative retainage held, released and outstanding, updated with every pay application.
Flagged discrepancies kept separate
Visible as their own group, not folded into a total that looks reconciled when it isn't.
Traceable to the source pay application
Every figure in the running balance links back to the specific G702/G703 it came from.
Who this is for
Most useful for anyone tracking retainage across a project that runs longer than a few months, or a portfolio of several projects at once: project accountants and controllers at general contracting firms, bookkeepers serving construction clients, and subcontractors whose own retainage is held under terms that differ from the contract above them.
Rolling several projects into one retainage picture
A firm with a single active project rarely needs more than one running balance. A firm running six or eight projects at once needs the same per-project balance, but also a way to see the total across all of them without manually adding up figures scattered across separate spreadsheets or separate tabs in the same one.
Each project's balance is maintained independently, on its own contract terms, and the portfolio total is simply the sum of those independent balances at any given moment — never a single blended calculation that would obscure which project actually holds how much. A question like “how much retainage across the portfolio is due for release in the next quarter” is answerable by filtering the same underlying data, not a separate report built from scratch.
This matters most exactly when it's asked under time pressure — a bonding company review, an ownership meeting, a cash flow forecast — because those are the moments a manually reconstructed answer is least likely to be both fast and reliable at the same time.
Where this feature stops
Retainage tracking maintains the running balance and flags what doesn't tie out — it doesn't decide when retainage is contractually due, doesn't negotiate an early release with an owner, and doesn't replace the project management system tracking the underlying scope of work. Those decisions and the full picture of how tracked retainage feeds into a reconciled pay application are covered in progress billing and retainage.
In what rhythm to reconcile
Retainage tracking follows the same billing cycle as the pay applications themselves — monthly, for most AIA-billed contracts. Checking less often than pay applications are submitted means the running balance falls behind, and a discrepancy from two periods back is far harder to trace once a third period has already been billed on top of it.
For a portfolio of projects on different schedules, batching the retainage check on a fixed monthly rhythm — rather than chasing each project's individual submission date — is usually the more sustainable habit, even though it means checking some projects slightly later than their own cycle would strictly require.
When a release covers more than one project phase
A project split into distinct phases — a base building phase and a tenant improvement phase under the same overall contract, for instance — can have retainage released for one phase while the other is still accruing. Treated as a single undifferentiated balance, a partial release like this looks like a large, unexplained drop in retainage held.
Where the contract defines separate phases with their own completion milestones, the running balance is tracked per phase rather than as one project-wide figure — so a phase-specific release is confirmed against that phase's own accrued retainage, and the other phase's balance continues accruing undisturbed.