Construction submittal log: what to track and how to structure it

A working construction submittal log does more than record what was sent and returned. It assigns ownership, tracks review and resubmittal dates, links approval status to lead time and installation need dates, and flags critical-path items before procurement risk becomes schedule delay.

The mechanical sub's rooftop units came back "Revise and Resubmit" six weeks ago, but the status was never recorded in the submittal log, and the PM just discovered the resubmittal never went out. The units carry a lead time measured in months against an installation date that hasn't moved.

That gap happens because many teams use a submittal log that records history but leaves upcoming procurement deadlines unflagged. The crew may be left waiting to set equipment while it remains in a manufacturing queue.

A good log identifies whose desk every submittal is sitting on and flags approvals that are about to collide with procurement deadlines.

What this article covers:

• Track identifiers, responsibilities, dates, lead times, statuses, and revision history to expose stalled reviews and procurement risks
• Build logs from project specifications and preserve consistent numbering throughout every resubmittal cycle
• See how poorly monitored spreadsheets can miss deadlines, fragment version control, and weaken closeout records
• Work backward from installation dates to establish realistic submission, review, approval, and procurement deadlines

What to track: the fields that make a submittal log work

A large commercial project's log can fill quickly, especially as construction gets underway. At that scale, the difference between a log that works and one that decorates a shared drive comes down to which columns you build in. Getting the distinction between RFIs, submittals, and specifications right up front keeps the wrong document types from ending up in this log at all.

A working submittal log consists of four key field groups: identification, responsibility, dates, and review status.

Identification fields

Every entry needs the following attributes:

• Submittal number: the spec section plus a sequential number (033000-01 for the first cast-in-place concrete submittal)
• Title: the written name of the spec section
• Description: specific enough to remove ambiguity ("RTU-1 through RTU-5 product data," not "HVAC equipment")
• Submittal type: product data, shop drawings, samples, test reports, or closeout submittals
• Package number: if the item belongs to a grouped package
• Revision number: increments with each resubmittal cycle

For responsibility, track the submitting subcontractor or vendor, the GC team member managing the document, the architect or engineer reviewing it, and ball in court.

Dates and lead times

Track these as separate columns:

• Date submitted to the GC
• Date the GC forwarded to the architect
• Required return date
• Actual return date
• Approval date
• Lead time: manufacturing and delivery
• Required on-site date

It’s important to track the first two dates separately. Combining them into one “date submitted” column hides how long the GC held the submittal, making it harder to pinpoint what caused a delay. The required on-site date drives the whole procurement chain and differs from the approval date. This is the same document-control discipline that keeps any project record set from drifting out of sync.

Build the submittal schedule with enough time for review, ordering, manufacturing, fabrication, and delivery, plus additional time for corrections and revisions.

Status, revisions, and ball in court

Don’t start work that depends on a submittal until it has the approval the contract documents require. The standard review actions are Approved, Approved as Noted, Revise and Resubmit, Rejected, and Under Review or Pending. Some projects also use “Approved as Noted, Resubmit.” Check the contract documents for how to handle it, and if it requires another review, wait until the resubmittal is complete.

Misreading a status causes problems for the crew. For example, an electrical foreman brings six workers to set switchgear because the log says “Approved as Noted.” But that approval required a resubmittal that was never sent. So the gear on the truck isn’t actually approved, and the general foreman has to decide whether to install it anyway.

Add a comments column to record what changed in each revision and why. Add a critical path flag for long-lead items, so they don’t look the same as paint samples in the log. In coordination meetings, the ball-in-court field shows who needs to act next.

A spreadsheet won’t keep the log updated for you. Someone has to recheck the spec book whenever a package or addendum arrives, retype each new revision, and spot ball-in-court fields that are out of date. On a large commercial project with hundreds of line items, that’s an ongoing job, not a one-time setup. The same problems show up in other spreadsheet-based field records.

How to structure and number the log

Organize the log by spec section. Build the initial log from the available contract documents as early as practicable, ideally at contract award or before mobilization. Update it as phased packages, addenda, and revised specifications are issued.

Use the "Submittals" heading in Part 1 of each CSI MasterFormat section as a starting point. Then check product descriptions, quality assurance paragraphs, warranty clauses, and the rest of the section for additional requirements.

Organizing by spec section can make review routing and duplicate detection easier, and it helps avoid cases where "light fixtures" and "lighting package" become two entries for the same submittal. A foreman searching the log for light fixtures finds two entries with different revision histories, can't tell which one the architect stamped, and calls the office instead of hanging fixtures.

For numbering, a common numbering convention pairs the spec section with a sequential number: 033000-01, 051200-02. Resubmittals get either an alphabetic suffix on the original number (25B for the second resubmittal of Submittal 25) or a revision increment appended to the same base number. Either works. Issuing a fresh number for every resubmittal severs the cycle history.

Related submittals that affect each other should move as a package for coordinated review; uncoordinated submittals may be rejected or returned without action.

Retain the original entry and every review cycle's dates, then advance its revision number for each pass. That history gives the team the timeline needed for schedule-delay analysis. A log that only shows current status may not establish the review timeline on its own, without supporting transmittals and correspondence to back it up.

Where a manually maintained spreadsheet can break down

A spreadsheet can work for a small, disciplined project, but it relies on manual updates, due-date monitoring, version control, and consistent ownership. As the number of submittals, reviewers, revisions, and long-lead packages grows, those controls become harder to maintain, and long-lead items can slip through when the file isn't checked regularly.

A returned "Revise and Resubmit" creates another open loop: fabrication may already be underway before the sheet metal shop discovers that the corrected flashing detail never completed another review.

On a commercial project with a long submittal list, every rejection can add another review cycle and push the work later.

Shared version control keeps the shop floor and office working from the approved drawing. Without it, the shop may fabricate from one drawing while the office has already approved its replacement. The shop then needs another fabrication pass, and the crew must replace the work in the field.

Then comes closeout. Acceptance of record documentation can be a condition of final payment. When records are incomplete, O&M manuals and warranty documents may still be missing at turnover. Complete records support timely payment and save the PM from reconstructing the package from vendors and scattered project files.

A long-lead submittal can live as a task with start and end dates and a named assignee. Named assignees, due dates, and notifications can make ownership of an open "Revise and Resubmit" loop visible, instead of it sitting unassigned in an inbox.

When a new plan version uploads, Fieldwire applies automatic version control: it slipsheets the new version over the old one and carries markups and annotations forward. Superseded sheets get a red watermark to reduce the risk of a crew building off a drawing the office already replaced. Test how revisions, markups, and linked tasks behave across your own devices and subscription tier before relying on it.

The mobile app works offline and syncs when the connection returns, which matters when the review happens in a basement mechanical room. Confirm the plan is synced to the device before the crew loses signal.

Run the log as a procurement tool

Treat the log as a procurement instrument and work backward from when material must be on the jobsite:

1. Installation date from the construction schedule: May 15.
2. Subtract 12 weeks of procurement lead time. Approval is needed by February 15.
3. Subtract the design team's 21-day review period. The submittal reaches the design team by January 25.
4. Subtract the GC's 10-day coordination review. It hits the GC by January 15.
5. Subtract 14 days of shop drawing preparation. The sub starts January 1.

That arithmetic tells you whether the approval timeline is achievable before the schedule proves it wasn't.

Lead times leave little room in the schedule. Confirm current supplier lead times for chillers, generators, switchgear, and other long-lead equipment before setting approval deadlines. Contract review periods are often shorter than actual design-team turnaround, so critical-path submittals need buffer for delays, resubmission preparation, and another review cycle.

Accountability tactics keep the log honest. Review it at every coordination meeting. PMs should also check aging submittals between meetings and raise delayed reviews before they threaten downstream work. Give every long-lead item one clearly identified owner.

If you're the sub, keep your own log

Subcontractors do not control the GC's overall submittal plan, so upstream delays can consume float before the trade sees the schedule problem. Run a parallel log: the date you handed the package over, the date it came back, and what the stamp said, cycle by cycle. Maintain that parallel log because the record can help in a claims case if the owner or GC slows approvals. Put the review period your subcontract specifies in a column next to each actual return date, so the gap is on paper before anyone argues about it.

Software doesn't do the backward-scheduling math for you; the PM and the sub still have to work those dates out. What software can do is take over everything downstream of that math: discovery, routing, ball-in-court, and notification, so the log stays current without someone rebuilding it by hand every week.

That's the gap between a hand-built spreadsheet and Fieldwire's Submittals module, which comes with Business Plus. Fieldwire's Submittal Extractor pulls submittal requirements out of your project documents so the log exists at contract award instead of week six. Extraction alone only solves the discovery problem this article opened with.

Ball-in-court routing, automatic notifications on stalled reviews, and status tracking are what actually stop an open "Revise and Resubmit" loop from sitting for six weeks. That’s part of the full Submittals workflow. Per Fieldwire’s current pricing page, the Business Plus plan includes both the Submittal Extractor and submittal management. The Pro and Business plans include the Submittal Extractor but not submittal management.

For each long-lead item, record the installation need date, required approval date, supplier lead time, current review status, next-action owner, and escalation date. That's what keeps a submittal log useful after the project moves past week six, not just at kickoff.

Start free