A submittal log that trails the model by three weeks is not a paperwork delay. It is rework and idle labour on the job. Here is how one live record inside Revit shows what a change touched, and who owns it.

Your Submittal Log Is 3 Weeks Behind the Model. That Gap Has a Number.

What the Three-Week Gap Actually Costs You

Three weeks doesn't sound like a gap. It sounds like normal. Submittals move at their own pace, the model keeps moving, and everyone assumes the paperwork will catch up. Then a shop drawing lands for a door frame sized off a wall that moved ten days ago, and the fabricator is already cutting steel. That is when the gap stops being a scheduling problem and becomes a line on your cost report.

Think about what happens inside that three weeks. The architect shifts a corridor. The mechanical engineer reroutes a duct to clear it. The model updates on every one of those changes, but the submittal log doesn't. It still reflects the old geometry, the old elevations, the old coordinated dimensions that were current when the log was last reconciled. By the time someone notices the mismatch, the submittal is approved against a version of the building that no longer exists.

That mismatch has a cost. A reissued shop drawing is annoying. A fabrication run that has already started is worse. Idle field labour is worse still, because a crew standing around waiting for a corrected submittal is burning payroll, equipment hours, and schedule float all at once. An unresolved conflict behind a crew can cost $15K to $50K a week, and a clash that sat 47 days can burn $28,000. Add the administration time spent chasing the discrepancy and the total gets uncomfortable fast.

Idle construction workers in hard hats stand beside an unfinished steel frame under a large clock, with a marked-up shop drawing and stacks of coins showing the

The real cost isn't any single line item. It's the compounding effect. Every week the log trails the model, the number of potential mismatches multiplies, because the model keeps producing changes and the log keeps accumulating approvals against old geometry. Three weeks of lag is three weeks of compounding exposure, and nobody is tracking it on the job.

Here is where it gets clearer. A record that updates the moment the geometry changes does not drift. If the submittal conversation were reconciled against that same record, the gap wouldn't exist because there would be nothing to reconcile. The model is the source, every export is versioned, and the question "which approvals sit on elements that have changed" has an answer the same day.

What BidLight actually does is keep one live record of the project inside Revit and Navisworks. You publish from the model, each publish is a snapshot, and any two revisions compare element by element. When the design changes, the comparison shows what moved. A submittal issue pinned to the door frame carries the sheet and the revision it came from, so the next comparison tells you at once whether the frame it was approved against is still the frame in the model.

Why the Log Falls Behind in the First Place

The log falls behind because it lives in a different system from the model. Submittals are tracked in a spreadsheet, a document management platform, or a project management tool that has no live connection to the Revit file. The model changes, and the log waits for a human to manually reconcile it. That human has forty other things to do, so the reconciliation happens on a cadence, not in real time.

That cadence is the problem. If the log gets reconciled weekly, the average lag is about half a week, which is manageable. If it gets reconciled monthly, or when someone remembers, or after the next coordination meeting, the lag stretches to weeks. Three weeks is not unusual in a firm running multiple projects with a lean administrative team. It is the natural output of a manual reconciliation process. It is also where the 11 hours a week go, spent working out which model version is current.

Isometric building model on the left and a submittal log sheet with unfilled rows on the right, above two timelines contrasting a short weekly lag with a long m

The fix is not to reconcile faster. The fix is to not need reconciliation at all. When the versions, the changes, and the issues all pull from the same live model record, the picture can never be more than a publish behind the geometry. That is the structural change, and it's the one most firms haven't made yet.

A lot of teams try to solve this with more meetings. A weekly submittal review, a coordination call, a shared tracker that everyone updates. That helps at the margin, but it still depends on people manually comparing two sources of truth. As long as there are two sources, they will drift apart, and the drift will have a cost. A 90-minute meeting that could have been a 15-minute look at a comparison is part of that cost.

What made the drift expensive is that the model, the shop drawings, and the log were never meant to agree in real time. Now that the model can carry the history, a firm that still runs them separately is leaving a measurable gap on the table every single month.

The gap is not a technology failure. It's a design choice. You chose to keep the log manual, and the manual log chose to trail the model by three weeks. Switching the source of truth to one live record inside Revit is what closes it.

What the Comparison Does With a Live Model Record

When the model is live and every export is versioned, the next useful thing you can do is look at exactly what changed. That is where element-level comparison comes in. It reads geometry and metadata directly from the two revisions and lists every element added, removed, or modified, grouped by category: structural, MEP, envelope, interior. A comparison takes about 15 minutes instead of a 90-minute meeting, and most of that time goes to confirming owners rather than hunting for files.

Two isometric building-model revisions side by side, with the changed elements highlighted in orange, above a list card of row-by-row differences between the tw

This is the practical side of submittal control. The model doesn't just tell you how many walls moved. It tells you which ones, in which category, on which level, and which open issues are pinned to them. From there, each issue carries its sheet and revision, and its owner gets the 6am digest. The review isn't guessed. It's assembled from the record, and the pinning is what routes each change to the right person.

How does the comparison work in practice? It starts with two published revisions, moves through the element-by-element diff, and lands on a short list of owners with something to do. BidLight does not run automated clash detection. It tracks the changes and the clashes and issues between revisions, pinned to the elements, so the person who knows the submittal can judge whether it still holds.

That shift changes what the coordinator does all day. Instead of hand-checking dimensions across three documents, they're reviewing, deciding, and applying judgment. That's the difference between paying someone to be a copy-paste machine and paying them to be a coordinator. It's also why the check can finish in minutes instead of days, because the parts that used to consume the schedule are the parts the model now handles.

There's a downstream effect too. When the comparison is live, it becomes usable for working through design options. You can test a change against the record immediately and see what it touches. That's not a report you generate on Friday. It's a conversation you have in the meeting, in the moment, with the model open.

An isometric building model with one changed element highlighted in orange, linked by dashed lines to the affected rows highlighted in a submittal log card besi

The Reconciled Record as a Service You Can Offer

Here's the part most firms miss. A current record is not just an internal efficiency gain. It's a service you can offer. If you can show a client that every approval sits against the current model, that the history behind it is defensible, and that the record of every change is auditable, that's something they will value.

Early reviews are the same story. Most firms give them away as part of the relationship. When the review is fast and tied to a live model, it stops being a favour and starts being a deliverable. The client gets a clear read they can plan against. You get a line on the invoice. The review becomes a service, not a loss leader.

The practical mechanics are simple. You publish the model, BidLight stores the snapshot, and you have a comparison in minutes. If the design changes, you publish again and the comparison updates. Issues read from the same record, so nothing falls three weeks behind. The whole thing is one live record of the project inside Revit.

That's also how you defend the picture in a meeting. When a client asks why a package was reissued, you don't point at a spreadsheet from last month. You point at the model and show the change and the issue together. A closed issue carries a screenshot, a tagged user, and the model commit that fixed it, so you can stand behind it when it gets challenged.

For firms that want the BIM work done rather than just the software, BidLight also does done-for-you delivery. Execution plans, 4D sequencing, fabrication detailing and spooling. So if the bottleneck is internal capacity rather than tooling, that's covered too. The pitch stays the same either way. Stop chasing scattered updates, keep one record, and show the work.

Isometric BIM building model with one floor highlighted in orange beside a crane, a 4D schedule bar chart, an execution plan sheet and a pipe spool with flanges

Plans run from Basics at $260 per licence per year to Max at $590, with custom Enterprise terms above that. Every plan includes unlimited projects. The math is straightforward. If closing the three-week gap saves one reworked shop drawing, or one idle crew day, the licence starts to pay for itself. Everything after that is margin you were previously giving away.

How to Tell If You Have This Problem

You probably have the gap if you can't answer a simple question in under a minute. What version of the model does the submittal log reflect right now? If the answer requires opening a spreadsheet, checking a timestamp, and correlating it against the Revit file, you have the gap. If the answer is a shrug, the gap is probably wider than three weeks.

Another signal is how often submittals come back for rework. If your team is regularly reissuing shop drawings because the dimensions don't match the current model, the log is trailing. Each reissue is a data point. Count them over a quarter and note what each one cost in idle crews and chasing. That's your gap number, and it's usually bigger than anyone expects.

You can also look at field idle time. If crews are regularly waiting on approved submittals that should have been approved days ago, the delay often traces back to a mismatch between the submittal and the model. The submittal sat waiting for clarification because the reviewer couldn't tell which version was current. That's the gap showing up as payroll you can't bill.

The last signal is simple. Ask the coordinator how long it takes to say what a design change touched. If the answer is days, the record is not live, which means the submittal log almost certainly isn't current either. The two go together. A live comparison and a current log are both symptoms of the same underlying thing, which is one record of the project instead of three.

A building model with one highlighted change on the left, a stopwatch at the top, and a submittal log with flagged stale rows on the right, above a calendar str

If two or more of those sound familiar, the fix is not to work harder on the log. The fix is to change what the log reads from. One live record of the project inside Revit, with every export versioned and every issue pinned to its element, is what makes the three-week gap structurally impossible rather than just better managed.

That is the whole point. The gap isn't a discipline problem. It's an architecture problem. Fix the architecture and the gap disappears, and the money it was costing you turns into margin instead.

Related Lessons

Support

Responses