Closing a Project: Final Costs, Retention & What the Next Bid Should Know
Projects end twice — once when the work stops, and again months later when the last invoice, the last claim and the last piece of equipment are finally dealt with. What a real closeout contains, why the final margin is almost never the one reported, and how to make the next bid better than the last.
The end of a project is the least managed part of it. The team is already on the next job, the client has what they wanted, and whatever remains — a supplier invoice still to come, a retention amount due in six months, equipment nobody has collected, a final margin nobody has calculated — belongs to no one in particular.
Which is how organizations end up unable to answer the only question that would make the next project better: did we actually make money on that one, and where did it go?
The margin you report is not the margin you made
A project's reported margin at the moment the work finishes is nearly always optimistic, and predictably so. Four categories of cost arrive after the celebration, and each of them is invisible on the day.
| What arrives late | Why it is missed | What it does to the margin |
|---|---|---|
| Supplier invoices for work already done | Committed but not yet billed, so not in the actuals | Straightforward erosion, sometimes substantial |
| Rework and warranty callbacks | Charged to overhead because the project is closed | Hidden entirely — the project looks better than it was |
| Staff time spent finishing off | Logged after the project stopped accepting time | Absorbed into the next job, distorting two projects at once |
| Equipment and materials never returned | Written off at a stocktake with no project attached | Appears as shrinkage rather than as project cost |
The third row is the quiet one. A team that spends two weeks tidying up a finished project while nominally on the next one damages both numbers simultaneously — the old project looks profitable and the new one looks like it started badly. Keeping a project open for time capture until the work genuinely stops costs nothing and prevents both distortions.
The distinction between committed and actual cost is the mechanism that makes the first row visible before it hurts — see project budget versus actual.
A team finishing off an old project while nominally on the new one damages both numbers at once: the finished job looks profitable, and the new one looks like it started badly.
What a closeout actually contains
A closeout is not a meeting. It is a short list of things that must be true before a project can be described as finished, and the value of writing it down is that each item acquires an owner.
-
Close the cost side, deliberately
Chase the outstanding supplier invoices rather than waiting for them. Convert every open commitment into either an actual cost or a cancellation, and stop new charges reaching the project once that line is drawn.
-
Settle the revenue side
Final invoice issued, variations agreed and billed, retention recorded with the date it becomes due. Retention is the amount most often forgotten, because it falls due long after everyone stopped thinking about the job.
-
Recover what belongs to you
Equipment, unused materials, borrowed tools, site keys. Filter the asset register by the project or the custodians and check each item back in — otherwise it becomes shrinkage with no story attached.
-
Hand over the documents
Whatever the client is contractually owed — drawings, certificates, manuals, warranties — plus your own copy, filed where the next person can find it during a dispute two years from now.
-
Compute the final position and write down why
Not just the number. The two or three sentences explaining where it diverged from the plan are the entire value of the exercise, and they take ten minutes while the memory is fresh.
The retention trap
For anyone working under contracts with retention — construction most obviously, but also equipment supply and some service agreements — closeout has a long tail. A percentage of the contract value is held back, released after a defect liability period that runs for months, and it is nobody's job to remember.
Two habits handle it. Record the retention amount and its release date as a receivable at the point of the final invoice rather than at the point it becomes due, so it appears in your receivables ageing rather than in somebody's memory. And record the defect liability period as a real date, because a callback inside that window is a cost you must not charge to overhead — it belongs to the project that generated it. The retention mechanics in a Kenyan construction context are covered in construction ERP.
The review that improves the next bid
Most project reviews produce a document nobody reads because they are written as narrative — what happened, in order, with names removed. Useful reviews are shorter and more specific: they compare what you estimated against what occurred, in the same categories you will estimate in next time.
The only review table that changes future bids
Illustrative, in KES. Notice that the useful output is not "we lost margin" — it is "we underestimate labour by roughly a quarter on this type of work, and our variation process leaks". The first is a scoreboard. The second two are corrections you can apply to the next quotation this week.
Unbilled variations are the most common single leak
Work done at the client's request, agreed verbally on site, never converted into a priced variation and never invoiced. It is rarely one large item — it is five small ones, each individually not worth the awkward conversation. Counting them at closeout is what makes the pattern undeniable and the process worth fixing.
Reuse what worked
The last piece of a closeout is forward-looking. A project that went reasonably well is a template: its task structure, its milestones, its cost categories and its sequence are knowledge that most organizations throw away and then reconstruct from memory on the next job.
Cloning a completed project as the skeleton of the next one is a small mechanical saving and a large quality one — the tasks somebody forgot last time are already there. The rule that keeps it honest: clone the structure, never the estimates. Estimates should be re-derived from what the review just told you, or you will carry the same 23% labour underestimate into every future bid.
What we do and do not do
What AWRA OpsHub does today
- Committed versus actual cost on a project, so open commitments are visible before they become invoices.
- Costs charged to the job from procurement, stock issues, time entries and expenses, giving a final position built from source records.
- Timesheet periods that can be locked, so a closed period stops accumulating late entries.
- Project status, so a finished project is distinguishable from an active one in every report.
- Project payouts with approval and posting, for programmes that disburse rather than invoice.
- Project cloning, so a successful structure becomes the starting point for the next job.
What it does not do
- No closeout workflow. There is no guided checklist that walks you through the steps and refuses to close the project until each is done.
- No retention tracking as a distinct object. Retention is recorded as a receivable with a due date by you; nothing models the defect liability period or releases it automatically.
- No warranty or defect-callback linkage. A callback after closure is new work — connecting its cost back to the originating project is a coding discipline, not an automatic link.
- No estimate-versus-actual learning. Nothing carries the variance from a completed project into the estimating of the next one; that transfer happens in your review, on paper.
The last two are the reason the review table above is worth writing by hand. The data to build it exists in the records; the habit of building it does not come with the software.
Our take
Keep the project open for cost and time until the work genuinely stops, chase the outstanding supplier invoices rather than waiting for them, record retention as a dated receivable at final invoice, and spend thirty minutes comparing estimate to actual in the same categories you bid in. Clone the structure of what worked; never clone the estimates.
See project time and budget
Committed versus actual cost, time and expenses charged to the job, lockable timesheet periods and project cloning for the next one.
Explore project costingFrequently asked questions
When should a project be closed for costs?
When the work genuinely stops, not when the client accepts delivery — those are usually two to six weeks apart, and the gap is where finishing-off time and late supplier invoices live. Closing early makes the finished project look better than it was and makes the next one look like it started badly, because that work goes somewhere. Convert every open commitment into an actual or a cancellation before you draw the line.
How do we stop forgetting retention?
Record it as a receivable with its release date at the moment you raise the final invoice, rather than waiting until it becomes due. That puts it into your receivables ageing where it is reviewed routinely, instead of relying on somebody remembering a contract clause six months after the team disbanded. There is no distinct retention object in the system that will chase it for you, so the discipline is in how you record it.
What belongs in a project review?
Estimated versus actual in the same categories you estimate in — labour, materials, subcontract, duration — plus a count of variations worked against variations billed. Thirty minutes, one table, two or three sentences of explanation. Narrative reviews describing what happened in order are far longer and change nothing, because they produce no number a future estimator can apply.
Can we reuse a project as a template?
Yes — cloning a project carries its structure into the next one, which is a real saving and, more importantly, brings along the tasks somebody would otherwise forget. The rule is to clone the structure and re-derive the estimates. Carrying old estimates forward is how a systematic underestimate becomes permanent, and the review you just did is precisely the correction you should be applying instead.
A client calls back with a defect after closeout. Where does that cost go?
To the original project, if you want honest project profitability — and that is a coding discipline rather than something the system does for you, since a callback is new work with no automatic link back. The temptation is to absorb it into overhead because the project is closed, which quietly makes every completed project look more profitable than it was and removes the signal that a particular type of work generates rework.
