A mobilisation advance is not an advance payment
One is a loan against future work, recovered from every bill. The other is a payment made early. Booking them the same way is how advances get paid twice.
Two things in construction are both called an advance, and they behave nothing alike.
An advance payment is money paid before delivery for a specific supply. You pay part of the value of an order up front; the material arrives; the balance is paid. The advance is part of the price of that order and is consumed by it.
A mobilisation advance is a loan. It is given at the start of a contract so the contractor can establish the site, bring plant, hire people and buy material before any bill has been raised. It is not payment for anything. It is recovered from subsequent bills, usually as a percentage deduction from each, until the balance reaches zero.
The words are similar, the accounting is opposite, and the confusion is expensive.
Why the distinction matters in the ledger#
An advance payment against an order reduces the amount still owed on that order. If the order is worth a certain sum and part of it has been paid, the remaining liability is the difference. Straightforward.
A mobilisation advance creates a receivable — the contractor owes you that money back — while the contract liability remains the full contract value. Two separate balances, moving in opposite directions, over the life of a project.
Book a mobilisation advance as if it were an advance payment against the first bill and two things go wrong. The first bill appears largely settled when it is not. And the recovery schedule has no balance to work against, so it either never happens or happens by hand.
The reverse error is worse. Book an advance payment against an order as a recoverable advance and the vendor is eventually asked to repay money that was part of the price. That conversation goes badly and it is entirely your fault.
What a mobilisation advance needs#
A recovery mechanism, defined at the start. Usually a percentage of each interim certificate, sometimes with a holiday at the beginning and a requirement that recovery completes before a stated point in the programme. The mechanism must be in the contract and in the system, because a recovery percentage that lives only in the contract will be forgotten by whoever prepares the third bill.
A running balance visible on every bill. Advance given, recovered to date, outstanding. Printed on the certificate. This is one line and it removes an entire category of end-of-project surprise.
Security, and a date on the security. Advances are commonly backed by a bank guarantee. Guarantees expire. A guarantee that expires while a substantial advance is still outstanding is no security at all, and the expiry date is the kind of thing that is diarised once, by one person, who then changes job.
Interest terms, or an explicit statement that it is interest-free. It is a loan. Whether it carries interest is a commercial decision, and leaving it unstated means the answer is decided later by whoever argues better.
The recovery that stops halfway#
The common failure is not that recovery never starts. It is that it stops.
Recovery is a percentage of certified value. If certification slows — because the work slowed, or because a dispute paused billing — recovery slows with it. If the contract is terminated or the scope reduced, there may not be enough remaining certified value to recover the balance at all.
At that point you are an unsecured creditor for the outstanding advance, holding a guarantee which may or may not still be valid, in a relationship which by definition has already gone wrong.
The forward-looking version of this question — if everything stopped today, what would we be owed and what security do we hold — is one very few organisations can answer quickly, and it is the whole reason the outstanding balance needs to be a number on a screen rather than a figure in a file.
Where advances get paid twice#
The most direct way to lose money on advances is to pay one twice, and it happens through a mechanism that has nothing to do with carelessness.
An advance is paid. Later, the full order value comes up for payment, because the record of what is still owed was not reduced. Or a stage payment schedule is created after an advance has already gone out, and the schedule is written for the full amount.
We hit a version of this in our own software, from the other direction. A payment made in stages — an advance first, then the balance — never wrote the field that meant this is paid, because when a payment has a schedule the stages are the payment record. Every queue that asked "is the paid date set?" was blind to money that had moved in instalments, and a fully settled order kept appearing in the queue asking to be paid again. Nine separate screens were asking that stale question, each written by somebody who reasonably assumed the stamp meant what it looked like it meant. The full account is a fact that had no owner.
Nobody paid twice, because a person noticed. But the system was asking them to, repeatedly, and a system that repeatedly asks for something wrong eventually gets it.
Two rules that prevent most of it#
An advance must be attached to something. An order, a contract, a stage. Money that leaves the building against a vendor name and nothing else cannot be netted off later except by memory. The same rule governs the small sums a labour contractor draws mid-month against the next bill — paying a labour contractor.
The remaining balance must be computed, never stored as an independent number. Remaining equals agreed less everything recorded as paid, worked out by one piece of logic that every screen asks. The moment two places compute it separately they will disagree, and each will be internally consistent, so nobody will notice for months.
The short version#
An advance payment is part of a price. A mobilisation advance is a loan.
One is consumed by the delivery it belongs to. The other has to be recovered, tracked, secured, and shown as a balance on every certificate until it reaches zero.
Booking them the same way is not a bookkeeping preference. It is how money goes out twice and comes back once. The related question of what to do when a stage payment is short of what was agreed is covered in paying less than agreed.