2 min read
Retention disputes and paper trails
Retention money gets held back until defects are fixed and paperwork is in order. A proper paper trail gets it released faster, and its absence is exactly what holds it up.
Retention exists to give the client or main contractor confidence that any defects will get fixed once the job is finished and everyone has moved on to the next job. Typically two and a half to five percent of the contract sum is held back, split between practical completion and the end of the defects liability period. In theory it's a straightforward mechanism. In practice, it's one of the most common sources of drawn out disputes in the industry.
The disputes usually aren't about whether defects exist. They're about whether they've been fixed, whether they were even defects in the first place rather than the client changing their mind, and whether the contractor has been given a fair chance to put things right. Without a paper trail, all three of those questions turn into arguments about memory and interpretation instead of facts anyone can check.
A well documented defects process looks like this: the snag or defect gets logged with a photo and a date when it's first raised, the contractor responds and the work gets carried out, and there's a photo and a date showing it's been fixed. If a client is refusing to release retention despite work being complete, that record is what turns a stalemate into a straightforward conversation, or if necessary, a straightforward adjudication.
Where contractors lose out on retention that's rightfully theirs is almost always the same pattern. Defects were fixed but never recorded as fixed. The client's list of outstanding items doesn't match what was raised. Or there's no clear record of when the defects liability period started, because practical completion itself was never formally confirmed in writing. Any of these gaps gives whoever is holding your money a reason to keep holding it.
None of this needs to be complicated. A snag list that tracks status, with photos at both ends of the process, closes the argument before it starts. That's the exact function the snags and defects tracking in Sitestack is built to serve, not just recording that something's wrong, but proving it's been put right.