The Advance Payment Is a Loan, and Three Numbers Have to Move Together
An advance is money you were paid before you earned it, secured by a bank guarantee and repaid out of your own certificates. The balance, the recovery and the guarantee must stay in step — and in most systems only one of the three is tracked.
· 6 min read · Written by Faceela Research & Editorial Team
Reviewed by Ahmed Hassan Algammal — Enterprise Systems Consultant
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
One thing to settle before the mechanics, because it causes real confusion in correspondence. Recovery of the advance payment, recoupment of the advance payment and repayment of the advance are the same event under three names. Recoupment is the word that tends to appear in the particular conditions and in bank correspondence; recovery is the word on the certificate; repayment is the word your accountant uses. If your contract says recoupment and your system says recovery, nothing is wrong — but check that the clause and the configured rule describe the same formula, because that is exactly the kind of mismatch that survives review by looking like a vocabulary difference.
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.
The advance guarantee is also the least dangerous of the instruments a contractor is carrying, because at least something in the business moves against it every month. The rest of them are set at issue and touched again only when a date arrives, which is the failure mode of the whole guarantee portfolio.
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.
There is a third consequence, and it lands on the VAT return. The advance was taxed when the money arrived; each recovery deduction repays a liability you already booked, and repaying a liability is not a credit note. A system that models the recovery line as a negative sale reverses output tax that was properly due, every month, for the life of the contract — which is the same distinction the tax point turns on.
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. In Movinti, the contracting suite we built on Odoo, both failures are refusals rather than reminders: recovery is derived from the outstanding balance on every certificate, and the system will not recover more than was ever advanced.