The Retainage You Can't Release Because Nobody Documented the Fix

The Fix Happened in March. The Proof Never Left the Field

Months of retainage on work your crew finished in March, and nobody can tell you where the paper went. The rebar was tied. The inspector signed off. Somebody in the field made a call about a detail that did not match the drawing, and the call was right. The work passed. Then the record never caught up to what happened in the dirt, and the owner's rep is holding retainage because the file does not show the fix.

You already know this story. It is the same story as the RFI that sits in an inbox for eleven days and the change that gets recorded after the crew already did the work. The proof is real but it is scattered across a superintendent's phone, a marked-up set in a truck, and an email thread from March that nobody wants to open.

Retainage is where that scatter gets expensive. Every month the fix stays undocumented, money sits on somebody else's balance sheet, not yours. Stretch that across several billing cycles and you are financing the owner's project with your own working capital. The cost is invisible until you cannot make payroll on a Friday.

The fix itself is usually small. A field adjustment. A substituted connection. A blocked duct reroute. Nobody argues the work was done wrong. The argument is about whether the record proves it, and a record that lives in five places proves nothing on a deadline.

This is where the conversation about documenting field fixes actually starts to matter. Not the software demo. The question of whether the model and your field record are the same document, or two documents that only agree by accident.

Why Retainage Gets Held and What Actually Releases It

Owners hold retainage for one reason and one reason only. Control. It gives them a reason to keep you engaged until closeout, and it gives them a cushion if something goes wrong. Your job is to remove the uncertainty that makes the cushion feel necessary.

That means proof, and proof has three parts. You need to show the work was scoped, the work was performed, and the work was accepted. Scope lives in the contract and the model. Performance lives in the field. Acceptance lives in an inspection or a signed sign-off. When any of those three is missing, the file looks incomplete and the money stays where it is.

Most firms are good at two of the three. The scope exists. The performance happened. The acceptance is a text message from a superintendent to a project manager who has since moved to a different job. That is not a record. That is a rumor with a timestamp.

Project training rarely covers this because it looks like a legal problem instead of a coordination problem. It is not. The fix starts in the model, where the element is defined and where the issue that will eventually need proof is first raised. If the field adjustment is not tied to an element, it becomes invisible the moment it leaves the model.

Once you start treating the model as the spine of the record, retainage turns into a housekeeping question instead of a fight. You are not arguing about whether the work happened. You are arguing about whether the file is complete, and that is a fight you can win with a click instead of a phone call.

What One Live Model Record Actually Does

BidLight keeps one live record of the project inside Revit and Navisworks. That is the whole idea. Every publish is a versioned snapshot with its own files, author, and milestone. When geometry changes, the comparison moves with it. No second file, no re-keyed notes, no Friday afternoon reconciliation between two versions of the truth.

Here is what that means for the retainage problem. The field adjustment that used to live in a superintendent's phone notes now gets raised as an issue pinned to the affected element. It carries the sheet and revision it came from. The change shows up in the comparison within minutes. The item that was going to disappear in March is already there, labeled, dated, and tied to a geometry change the owner's rep can see in the model.

When it comes time to close it, the rule does the work. An issue closes only with a screenshot, a tagged user, and the model commit that fixed it. BidLight does not run automated clash detection. It tracks the changes and the issues between revisions, pinned to the elements. The closed issue is the acceptance record, and it was made when the work happened, not nine months later.

When you sit down at the closeout meeting, you are not reconstructing what happened. You are showing what happened. The revision history in the model is the same revision history the architect is looking at. Nobody has to take your word for it because the record is not yours alone.

That matters because retainage fights are usually credibility fights. The owner's rep is not trying to keep your money. They are trying to make sure their file is clean. If the file is clean on both sides, the money moves.

On the coordination side, the numbers are plain. Working out what changed takes about 15 minutes instead of a 90-minute meeting. Across a billing cycle, those meetings stop being a monthly fight, and the hours come back to the job.

How Closed-With-Proof Changes the Closeout

Proof is not about robots checking your work. It is about the record staying consistent through every change. A closed issue holds a screenshot, a tagged user, and the model commit. Those three things make the field adjustment visible, because the issue exists the moment the geometry change does.

People ask how a closeout file gets assembled and expect a binder. The honest answer is that the model does two jobs. It shows what is there, and it shows what was there before. Your job is still the judgment call. The record just makes sure the judgment call leaves a trail.

That trail is the difference between retainage you can release and retainage that sits. A versioned record is useful during the job. It is more useful at closeout, when someone asks you to prove that the change you raised in April was the change the crew built in March. If the model says yes, and the issue says yes, the file is complete.

Think about how bad this gets on a design-build job with 40 changes in a quarter. Nobody can hold that in their head. Without a record tied to the model, you are relying on the memory of the person who was there, and that person is on a different job now.

The 4D view is the same idea with a longer horizon. Design, schedule, and field record all live on one model. When the retainage question comes up, the answer is already in the file. You are not building a case. You are opening a document.

BIM Versus Traditional Records, Told Through a Retainage Check

BIM versus traditional coordination is usually framed as a speed argument. It is faster, sure, but that is not the point. The point is that a traditional file is a snapshot, and a BIM record is a history. A snapshot is useless nine months later. A history is not.

In the traditional model, your issue list is a spreadsheet. The drawing is a PDF. The field condition is a photo on somebody's phone. The closeout file is a binder you assemble after the fact. Four sources, four versions, and none of them talking to each other. Assembling that binder is a week of your project manager's life, and the money does not move until it is done.

In a BIM-first workflow, the model is the source. The issues read from the model. The field change is raised on the element. The sign-off ties back to the modeled element. The closeout file is a filter, not a project. You run a report on the issues that were closed, attach the acceptance docs, and send it. That is it.

This is also where the services angle shows up. If your firm can produce that record as a service, you stop giving it away. Owners value a closeout file that is clean the first time. It is the same model work you are already doing, just packaged instead of buried in overhead.

That is the quiet advantage of keeping the record inside the model. You are not just coordinating. You are building a defensible history that pays you twice, once during the job and once at closeout.

What to Do Before Your Next Billing Cycle

Pick one active job with retainage held. Open the model and look at the changes made since the last billing cycle. For each one, ask whether the field record matches what is in the model. Wherever it does not, fix it now, while the crew still remembers the call.

Then look at the issues. Is there one for that field adjustment? If not, the adjustment is already invisible to whoever signs the closeout. Add it, pinned to the model element it belongs to. That issue is the bridge between what happened in the field and what gets released.

If you are wondering how to protect your position in a way that actually holds, this is the answer. Do it through the model. Learn to read the geometry, learn to read the comparison, learn to tie an issue to a modeled element. The pinning skill is the entry point. The record skill is what keeps the job clean.

BidLight runs from $260 per licence per year on Basics to $590 on Max, with custom Enterprise terms and unlimited projects on every plan. If you would rather hand it off, we do the BIM work directly: execution plans, 4D sequencing, fabrication detailing and spooling. Either way, the goal is the same. Stop chasing scattered updates. Get the fix on the record, then close out without a nine-month argument.

The one thing to remember is simple. One live record of the project inside Revit, with every issue pinned to its element and closed with proof. That is what gets the retainage released, because the proof never leaves the file in the first place.