Start with what the log is for
A submittal log is not a filing index. It is a procurement schedule wearing a different name. Every row is a piece of material that cannot be ordered until that row reaches an approved status, and every day the row sits open is a day of lead time you no longer have.
Logs that get treated as documentation get updated monthly and are useless. Logs that get treated as schedules get updated weekly and prevent the phone call about why the switchgear is not on site.
The columns
Identity
- Submittal number — sequential, or spec-section based (
23 34 00-001). Section-based numbering is easier to audit against the spec book. - Spec section — the section that required it. This is the column that proves the log is complete.
- Description — what the item is, in the words a person would use.
- Type — product data, shop drawing, sample, certification/QA, or closeout. Types have different lead times and different reviewers.
Responsibility
- Responsible party — the sub or supplier who owes it.
- Ball-in-court — who has it right now. The most-used column in any weekly meeting.
The cycle
- Date required — driven by the schedule, not by hope.
- Date received from sub
- Date submitted to A/E
- Date returned
- Action — Approved / Approved as Noted / Revise and Resubmit / Rejected / For Record Only.
- Revision — 0, 1, 2. A visible resubmittal count is how you spot a sub who is not reading the comments.
The scheduling columns most logs are missing
- Lead time — weeks from release to delivery.
- Required on site — from the construction schedule.
- Float — required-on-site, minus lead time, minus remaining review cycles, minus today. When this goes negative the row is a schedule problem, and you want to see that in week six rather than week twenty.
Build it from the spec, not the drawings
This is the part that determines whether the log is right.
Open the project manual. For every technical section in your scope, read the PART 1 SUBMITTALS paragraph. Create one row for every item it names. Section 23 05 93 asks for a TAB agency qualification, a sample report form, and a final report — that is three rows, not one row called "TAB."
A log built by scanning the drawings for equipment will produce a plausible-looking register that is missing every certification, every qualification statement, every design-mix, and every closeout item. Those are the ones that surface at the worst possible moment, because nobody was tracking them.
Then reconcile: check Section 01 33 00 for procedural requirements (copies, format, portal, review period), and check the schedule to set required-by dates by working backward — installation date, minus lead time, minus at least two review cycles.
Keeping it current
Weekly, not monthly. Three questions:
- What changed status since last week?
- What is past its required-by date, and who has it?
- What has negative float — regardless of whether it is late yet?
The third question is the one that earns the log its keep. An item with a sixteen-week lead time and eleven weeks until it is needed is a problem today, even though nothing about it is currently overdue.
Getting the log built without doing it by hand
Reading a spec book section by section and extracting one row per required submittal is precisely the kind of work that should not consume a PM's week — it is mechanical, it is high-volume, and it is exactly where fatigue causes omissions.
We build this for contractors: the system reads the project manual, produces the log with one row per required submittal per section, sets required-by dates against the schedule and lead times, tracks the review cycle with ball-in-court, and generates the transmittals. Any trade, any division.
See the submittal tools, or the trade-specific builds for mechanical, Division 22 and 23 and electrical, Division 26. If you want the background on why a bad log is expensive, we wrote that up here. For the process the log tracks, start with what submittals are.