The submittal log says approved and the inbox says otherwise

When the log says approved and the thread says otherwise, the usual explanation offered is that somebody forgot to update the spreadsheet. That is a symptom. The cause is that approvals can arrive by a route the log does not watch, and that the vocabulary between approved and rejected is not defined anywhere, so two people record the same reviewer action differently and both believe they are right. The check that separates the two is an ageing report by ball-in-court, cross-referenced against the last dated communication on each open item.

This gets expensive at exactly one moment: when a delay claim is being argued and the log is the contemporaneous record. A log that was reconstructed the week before it mattered is worth very little, and everyone in the room knows it. The value of the log is not that it is current — it is that it was current at the time.

The ageing report that finds where the log parted from reality

1. Export every row that is not closed, with its status, the party currently holding it, and the date that status was set.
2. Beside each row, put the date of the last communication about that item from any source — the review platform, the shared mailbox, the transmittal record.
3. Compute the gap between the two dates. Rows where the last communication is more recent than the last status change are the drift set, and they are usually a small fraction of the log.
4. Sort the drift set by holder. Drift concentrated on one reviewer is a routing problem; drift spread evenly is a vocabulary problem.
5. Read the 10 oldest items in full, including the attachments. What you are looking for is the sentence in an email that decided something the log never recorded.
6. Count how many open rows have no ball-in-court at all. Those items are not late, because nobody is holding them, which is the quietest failure on this list.

Two numbers come out of this: what proportion of open items drifted, and whether the drift clusters. On a set of 300 register rows the drift set is often under 30, and reading 30 items is a morning's work that produces a specific answer rather than a general complaint.

Five ways a status changes without the log hearing about it

The first row accounts for most of the volume and is the least interesting. The second and third are the ones that survive a platform migration, because they are definition problems wearing a tooling costume.

Approved as noted is two decisions wearing one word

Review stamps are not standardised across consultants, and that is the root of this. One engineer's markings mean proceed and incorporate the comments; another's mean proceed on everything except the clouded item; a third stamps the same way but expects a revised copy for record. All three arrive as a returned document with annotations, and the log has one field to hold what happened.

Treat the action as carrying 2 separate facts, and record both. The first is whether fabrication or ordering may proceed. The second is whether a further submission is owed, and by when. A state that answers only the first leaves an obligation nobody is tracking; a state that answers only the second stops work that was never stopped. Where the reviewer's comments go further and start directing how work is done, they carry the same risk that makes an RFI response that does not create a claim a discipline rather than a formality — and that is worth logging verbatim rather than summarising.

A resubmittal is a revision, not a new item

Opening revision B as a fresh row is the single most common structural mistake in a submittal log, and it is attractive because it makes the report look better. The new row has an age of zero. The original obligation, which has now been outstanding for 9 weeks across 2 cycles, disappears from the ageing report entirely.

Model it the other way round: the item is the obligation created by the specification, and submissions are revisions attached to it. The item keeps its original required-on-site date and its original first-submitted date; each revision carries its own sent date, returned date, action and reviewer. Cycle count then becomes a field you can report on, and 3 cycles on one item is a signal worth surfacing long before it becomes a delay. Items whose obligation is triggered later rather than now are a related but different shape, handled in deferred submittals and who owns the clock.

One write path, and what it costs to enforce

Every status change must enter the record through one door. Whether the log lives in Procore, in Autodesk Construction Cloud or in a spreadsheet on a server is beside the point — the failure is identical in all 3. What makes it hard is that the reviewer with authority to approve is often the person least willing to log in to your system. So do not fight that; capture the other route instead.

1. Give every item a durable reference and require it in the subject line of anything sent about it.
2. Route submittal correspondence through one monitored address rather than individual inboxes, so a reply is a record by default.
3. Parse inbound mail into a proposed status change, and hold it in a review queue rather than applying it. A machine reading of a reviewer's sentence is a draft, not a decision.
4. Have the document controller confirm or correct the proposal in one click, which is the only step that touches the log itself.
5. Store the source message and the returned file against the item, so the row's status is always traceable to a document rather than to a memory.
6. Make status changes append-only, with a name and timestamp on every one. Overwriting is what makes a log unusable as evidence.

Ball-in-court deserves its own note, because it is a custody field and not a label. A transfer only counts when the receiving party has acknowledged it; otherwise the item sits in a state where the sender believes it is gone and the recipient has never seen it. That is the same discipline as custody transfer that crews will actually do on site — the record has to capture an acknowledgement, not just a send.

The value of a submittal log is not that it is current today. It is that it was current on the day the thing happened.

What a log in perfect order still will not tell you

A correct log records what happened to each obligation. It does not know whether the approved product still matches the drawings, and that is the gap that bites on a project with active revisions: a sheet reissue can invalidate a submittal that is closed and correct in every field. Feeding a published change list into the log — flagging items whose basis sheet has moved — is part of doing a sheet-set comparison properly rather than an extra.

It also does not know whether the data on the submitted document is right. Equipment submittals are checked against a schedule, and if that schedule was extracted from a drawing with rows shifted by one column, the log will faithfully record the approval of a mismatched unit. Status tracking and content checking are two different jobs, and only one of them is solved here.

The build this needs is small: an item-and-revision model, an append-only status history, one inbound mail route with a human confirmation step, and an ageing report that runs weekly. That is the kind of narrow, well-bounded system we scope under MVP and product builds. This page sits inside drawings, specs and construction document intelligence, part of our construction and contracting work.

• submittals
• project controls
• status tracking
• document ai