What Is a Submittal Log, and How Do You Keep One?

A submittal log is the master tracking record for every submittal on a construction project — each product data sheet, sample, shop drawing, and certification a contractor has to get reviewed and approved before the corresponding work goes in the ground. At its simplest, it answers one question for every required item on the job: where is this in the approval process right now?

If you only remember one thing: the submittal log is not the submittals themselves. It's the index and status board that sits on top of them. The documents live in folders, emails, and PDFs; the log is the single place that tells you which of them are outstanding, which are approved, and which are about to hold up the schedule.

What a submittal actually is

On most commercial projects, the specifications require the contractor to submit information about the products and assemblies they intend to use, so the architect or engineer can confirm they match what was specified. A submittal is that package of information. Common types include:

• Product data — manufacturer cut sheets and technical specs for a specified product.
• Shop drawings — fabrication or installation drawings prepared by a subcontractor or supplier (steel, millwork, curtain wall, etc.).
• Samples — physical examples of a material, finish, or color for the design team to approve.
• Product certifications and test reports — documentation that a product meets a code or performance requirement.
• Closeout submittals — warranties, O&M manuals, as-builts, and attic stock required at the end of the job.

Each of these moves through a review cycle: the contractor sends it to the design team, the design team marks it up and returns a disposition, and depending on that disposition the item is either cleared for fabrication or sent back for revision.

What belongs in the log

A usable submittal log captures enough about each item to manage it without opening the underlying document. At minimum:

Field	Why it matters
Spec section	Ties the submittal to the requirement that created it (e.g. 09 51 00 Acoustical Ceilings).
Submittal number	A stable identifier for referencing the item in correspondence.
Title / description	What the item actually is.
Type	Product data, shop drawing, sample, etc.
Responsible sub or supplier	Who owns producing it.
Date sent / date returned	The backbone of any schedule analysis.
Status / disposition	Approved, Approved as Noted, Revise & Resubmit, Rejected.
Revision number	Which round of review you're on.

The disposition language matters, and the precise meaning matters more than the casual reading. "Approved as Noted" is not a clean approval — it's an approval conditioned on the contractor fully complying with the reviewer's written comments, and failing to incorporate those comments typically nullifies the approval. "Revise and Resubmit" means the reviewer believes the item cannot be approved as furnished and has to go around again. Logging the literal disposition — not a paraphrase — protects you when a question comes up months later.

One caveat worth knowing: the four labels above (Approved, Approved as Noted, Revise and Resubmit, Rejected) are the canonical set, but they aren't universal. Many architects and engineers have moved away from the word "Approved" — using "Reviewed," "No Exceptions Taken," or similar — to manage their own liability, even though courts have generally treated that language as equivalent to approval. The lesson for the log: record the exact words on the reviewer's stamp rather than forcing them into your own categories.

Why the log falls apart

Most submittal logs don't fail because the format is wrong. They fail because the log and the documents drift apart. The spreadsheet says an item is "in review," but the approved PDF is sitting in someone's inbox and never got marked. Or three different people maintain three different versions. Or the same item gets logged twice with slightly different titles, so nobody trusts the count.

The discipline that keeps a log honest:

1. One source of truth. Pick one log and make every status change happen there. A log nobody trusts is worse than no log.
2. Log the item the moment the spec requires it, not when it's submitted. A log built from the specification shows you what's outstanding, which is the whole point. A log built only from what's already been submitted hides the gaps.
3. Track revisions under one entry. When a submittal comes back "Revise and Resubmit," the resubmittal is a new revision of the same item — not a brand-new line. Stacking revisions under one entry keeps the count true.
4. Tie status to the actual document. The status field should never be more current than the file it describes. If the log says approved, the approved file should be one click away.

Building the log from the specification

The strongest submittal logs are generated directly from the project's specification book. Each spec section lists its own submittal requirements, so reading the spec gives you the complete set of items the project will ever require — before a single one has been submitted. That turns the log from a record of what happened into a forecast of what still has to happen, which is what lets a project manager see a bottleneck coming instead of discovering it after the fact.

The bottom line

A submittal log is a living status record, not a filing cabinet. Keep it built from the specification, keep every status change in one place, keep revisions stacked under their original item, and keep the status honest against the real document. Do that and the log becomes the early-warning system for the whole approval process. Skip it and you find out a critical material was never approved on the day it was supposed to ship.

TuttoHQ builds the submittal log straight from your spec book and keeps each item's status tied to the actual approved file, so the log is always something you can trust. Start a free trial to see it on your own project.