Retention money is a balance, not a memory
Retention is money you have earned, been billed for, and not been paid. It is held against defects and released later, and most people track it in their heads.
Retention is a portion of every payment that is deliberately not paid.
The contractor does the work, the work is measured, a bill is certified — and then a stated percentage of the certified amount is held back by the employer rather than paid across. It accumulates through the project. It is released later, in stages, once the work is complete and once a defect liability period has passed without the work falling apart.
The percentage, the cap, the timing of release and the length of the defect period are all contractual. There is no universal figure, and anybody who quotes you one without reading the contract is guessing.
What it is for#
Two things, and they are different.
Security against defects. If something fails during the defect liability period and the contractor does not come back to fix it, the employer has money in hand to have it fixed by somebody else. That is the stated purpose and it is a reasonable one.
Leverage for completion. Retention gives the contractor a financial reason to finish properly and to attend to a snag list. It is the part everybody understands and nobody writes down.
Both are legitimate. It is worth knowing which one is actually operating in a given argument, because they resolve differently.
Why it is difficult to track#
Retention has an awkward shape for an accounting system.
It is not a discount — the contractor earned it and it is owed. It is not an outstanding invoice — nothing further needs to be billed. It is not a liability with a fixed date — the release date depends on completion, which is an event, not a calendar entry. And it accrues in small amounts across dozens of bills over years, so it is never a single number anybody set out to record.
The result is almost universal: retention lives in memory. The contractor knows roughly what they are owed. The employer knows roughly what they are holding. The two figures are different and neither is written anywhere as a total until somebody asks.
On the contractor's side this is money already earned and often already spent on the job that generated it, and a contractor who has not priced that wait into his rate is lending it — one of the layers in quoting a rate you can live with. On the employer's side it is a liability that does not appear anywhere obvious and then arrives all at once.
Making it a balance#
The design that works is to stop treating retention as a special case and treat it as a payment stage that has not fallen due yet.
That single move solves most of it. A payment schedule can already hold stages with amounts and dates. If a retention deduction is a stage on that schedule, marked as retention, with its date meaning the release date rather than the due date, then everything that already works for payment stages works for it: it shows up in a forward view of money owed, chasers chase it when the date nears, and releasing it is the ordinary act of marking a stage paid.
That is how we built it in our own system, and the reason we built it that way was to avoid inventing a second mechanism. A second mechanism means a second set of screens, a second set of rules, and a second place for the truth to live — which is the shape of problem described in a fact that had no owner, where the same question was being answered independently in nine places and the answers had drifted.
Alongside it sits the thing nobody had before: a register. Every vendor's held money, totalled in one place, sorted by release date, with past-due releases called out. Held money the company owes but is holding becomes a number anybody entitled to see it can read, rather than a memory distributed across a hundred task pages.
The questions a retention register has to answer#
If you are building or buying one, these are the questions. A system that cannot answer all five is not tracking retention, it is storing it.
- How much are we holding in total, right now?
- From whom, and against which contract?
- When is each amount due for release, and on what event?
- What has already been released, when, and who authorised it?
- What is past its release date and still held?
The fifth one is the one that actually costs money, in both directions. Held money past its release date is money the other party is entitled to and is probably already unhappy about. From the employer's side it is a liability quietly ageing. From the contractor's side it is working capital sitting in somebody else's bank account.
Release is an event, not a date#
The most common error in a retention system is to store a release date and treat it as automatic.
Release is usually conditional: on practical completion, on a certificate, on the expiry of a defect period that itself starts from an event. Storing a date without storing what the date depends on means the date silently becomes wrong as soon as the programme moves — which on a construction project is immediately.
The workable arrangement is to store both: the condition in words, and the current expected date. When the condition is met, the date becomes real and the stage falls due. Until then the date is a forecast and should be shown as one.
This is a specific case of a general principle we keep returning to — the app should tell you why. A release date with no stated basis is a number people either trust wrongly or ignore entirely, and both are worse than a forecast that says what it is waiting for.
Retention against other deductions#
Retention is not the only thing withheld from a certified bill, and confusing the categories makes reconciliation impossible.
A bill may have retention held, plus statutory deductions, plus recovery of an advance, plus set-off for something the contractor owes, plus a deduction for work not accepted. These have completely different legal characters and completely different futures. Retention will be released. An advance recovery will not — it is repayment of money already paid. A deduction for short work is gone for good.
Lumping them into one "deductions" figure on a certificate is common and it destroys the ability to say what is owed to whom. Each needs its own line and its own running balance. The mechanics of one of them are set out in set-off.
The short version#
Retention is earned money, deliberately unpaid, held against a future condition.
The failure mode is not fraud. It is that nobody totals it, because it accrues in fragments and has no natural home in a ledger.
Give it a home — as a payment stage whose date is a release date — and it stops being a memory and starts being a balance.