The Advance Payment Is a Loan, and Three Numbers Have to Move Together
· 6 min read · Faceela
An advance payment is money the client pays you at the start of a job, before you have earned it, so that you can mobilise. It is not revenue and it is not a deposit. It is a loan: secured by a bank guarantee you provide, and repaid by deductions from your own payment certificates as the work proceeds.
Three numbers have to move together for the whole arrangement to stay honest.
The outstanding advance balance — how much of the loan is still unrepaid. The recovery deducted to date — how much has come back out of your certificates. And the face value of the guarantee you are paying a bank to maintain. Every recovery deduction should reduce the first and, on most arrangements, permit a reduction of the third.
In most systems only the middle number is tracked, because it is the only one that appears on a document. The balance is derivable and nobody derives it. The guarantee sits with whoever handles bank facilities and is reviewed when it is about to expire, which is why contractors routinely pay charges on guarantees far larger than the exposure they secure.
That is the whole answer. The rest of this article is the mechanics, and where each of the three quietly goes wrong.
Recovery is a formula, not a percentage
The simplest arrangement deducts a flat percentage from every certificate until the advance is repaid. Many contracts are not that simple.
A common alternative delays recovery until certified work passes a threshold, then recovers at an accelerated rate so that repayment completes by a second threshold — the intent being that you keep the working capital during the early, cash-hungry phase and repay it while the job is generating.
The thresholds and rates are contract fields, and like every other figure in these arrangements they are amended in the particular conditions as a matter of routine. Any system, template or article that states fixed numbers is describing a different contract than yours.
Two properties matter more than the specific shape:
Recovery must stop at zero. Once the advance is fully repaid, deductions stop. A system that applies a percentage rule without reference to the outstanding balance will keep deducting past full recovery, and you will be funding the client out of your own certified work.
Recovery must be derived from the balance, not typed. The deduction on this certificate is a function of the cumulative position — the same cumulative logic that governs the certificate itself. A recovery figure entered by hand each month is a number that will eventually disagree with the balance, and the disagreement will surface at final account when it is most expensive to resolve.
The guarantee should shrink, and usually does not
This is the part that costs real money and gets almost no attention.
The advance payment guarantee is an instrument issued by your bank in the client's favour, and you pay for it — commission, and usually a hold against your facility limits that constrains what else you can borrow. Its face value is the client's protection against the advance not being repaid.
As you repay the advance, the client's exposure falls. Most arrangements permit the guarantee value to be reduced in step, and some require it. Whether it actually gets reduced depends entirely on whether somebody asks.
The pattern is ordinary and expensive: an advance is recovered steadily over eighteen months, the guarantee stays at full face value for the whole period because reducing it is nobody's specific job, and the contractor pays commission on the original amount long after most of it has been repaid — while the facility headroom that would have supported the next project's bonds stays occupied.
None of that requires clever software. It requires the outstanding balance to be a live figure and the guarantee to be a record attached to it, with reduction points that raise a task. What makes it a systems problem rather than an admin one is that the two records normally live in different places — the recovery on the certificate in the commercial system, the guarantee in a finance folder — and nothing joins them.
Two deductions on one certificate, behaving nothing alike
Advance recovery and retention appear side by side in the deductions block of the same payment certificate, are both expressed as amounts withheld, and are frequently modelled the same way. They are opposites.
| Advance recovery | Retention | |
|---|---|---|
| What the money is | Repayment of cash already received | Your earned revenue, withheld |
| Direction | Reduces a liability | Creates an asset |
| Ends when | The advance reaches zero | Two release events, years apart |
| Secured by | A bank guarantee you pay for | Nothing; the client simply holds it |
| If mis-modelled as a discount | Revenue overstated, liability hidden | Revenue understated, asset lost |
The last row is the one that damages accounts. Treating advance recovery as a reduction of revenue means the original advance was never recognised as a liability, so the balance sheet shows neither the cash obligation nor its repayment — and the profit and loss shows revenue that fluctuates for reasons unconnected to work done.
Retention modelled the same way fails in the opposite direction, which is set out in retention as a loan you made without deciding to. The two errors can and do coexist in the same system, on the same certificate, cancelling each other out well enough that the totals look plausible.
What it does to the cash forecast
The advance distorts early cash in a way that is entirely predictable and routinely forecast wrong.
In the first months a contractor holds cash they have not earned. Utilisation looks strong, the bank balance looks healthy, and the temptation is to read that as project performance. It is not — it is a loan sitting in the account, and it will be withdrawn through deductions from certificates that would otherwise have been paid in full.
The forecast that matters is the one that nets the recovery schedule against the certification schedule, so the month where recovery accelerates does not arrive as a surprise. That schedule is knowable from the day the contract is signed: the advance amount, the recovery rule and the programme give you every deduction in advance.
Almost nobody produces it, for the same reason as the guarantee reduction — it is derivable, nobody derives it, and the hours that would go into building it by hand each month are the same category the cost of chaos calculator converts into an annual figure.
What to make a vendor show you
On one contract:
- Record an advance with its amount and its recovery rule, and show the outstanding balance as a field.
- Run certificates and show recovery deducted automatically, derived from the balance.
- Show recovery stopping by itself at full repayment, with no instruction.
- Show the advance as a liability on the balance sheet, decreasing — not as negative revenue.
- Attach the guarantee, and show a reduction point raising a task when the balance crosses it.
- Produce the forward recovery schedule against the certification programme.
- Show advance recovery and retention on the same certificate, each computed by its own rule.
Item 4 is the one to insist on, because it is the one that is invisible until an auditor or a lender asks, and by then the history has been posted that way for a year.
The wider set of things a contractor's system has to hold is in what a contractor's system has to do before it is worth buying.
The short version
The advance is a loan. It has a balance, a repayment rule and a guarantee you are paying for, and the three only stay consistent if the balance is derived rather than typed and the guarantee is attached to it.
Get it wrong in the accounts and you overstate revenue while hiding a liability. Get it wrong operationally and you keep paying a bank to guarantee money you have already repaid.
Neither failure is difficult to avoid. Both are extremely common, because the advance is set up once at the start of a job and then nobody owns it. What that looks like built, alongside the certificate, the bill and retention, is on the contracting page.