Construction Submittal Log Template: Columns That Work

Paste this header row into Excel or Google Sheets and you have a working log.

You can add a lead-time column for long-lead items, and a "delegated design" flag for anything that needs a stamped engineer's calculation. Don't add columns nobody will fill in. A log with blank columns stops being trusted.

The log starts life as a list of what the contract requires. It is not a list of what subs happen to send you.

1. Read Section 01 33 00, Submittal Procedures. In a CSI-format project manual this is where the project's rules live: how many copies, how transmittals are numbered, review durations, and whether action and informational submittals travel separately. Many versions require action and informational submittals from the same spec section to go in separate packages with separate transmittals (UFGS 01 33 00). If your spec says so, your log needs separate rows.
2. Open every technical spec section and find its submittals article. Each item listed there is one row.
3. Add Division 1 items such as the schedule of values, the construction schedule, and the safety plan if the spec treats them as submittals.
4. Assign each row to the sub or supplier who owns the work, so there is a name against every line.
5. Back-schedule the "Required by" date. Work backward from the date the material must be on site: fabrication time, then review time, then the time to prepare and check the package.

Some specs include a blank submittal register as an attachment. The Unified Facilities Guide Specification, for one, includes a Submittal Register as Attachment A to its 01 33 00 section. If yours does, use it as the starting point and add the columns above it lacks.

Specs split submittals into two types, and the type decides whether work can proceed.

These definitions are paraphrased from project specifications that follow the CSI model, including Los Alamos National Laboratory's 01 33 00. Your project's own wording governs. Read it before you rely on this table.

The contract language backs the same sequencing. Under AIA A201 Section 3.12, the contractor may not perform work that requires a submittal and review until the submittal has been approved. The A201 also says submittals are not Contract Documents, and that the architect's approval does not relieve the contractor of deviations from the contract unless the contractor specifically identified them. Check the edition in your contract, because 1997 and 2017 wording differs. See the AIA Contracts guide to A201 Section 3.12.

There is no single national standard. Most projects use a version of four responses. Alaska DOT's submittal register, for example, uses status codes A (approved), C (conditionally approved as noted), R (resubmit, insufficient information for review) and D (disapproved or rejected) (Alaska DOT Form 25D-030). Other projects write them out.

Use whatever vocabulary the spec uses. If the spec lists the codes, copy them exactly. Don't invent your own, because the reviewer's stamp has to match the log.

One caution from practice. Reviewers sometimes overuse "approved as noted" on items that really need another look, such as control sequences. An ACHR News column argues those should come back as revise and resubmit (ACHR News). As the person keeping the log, you can flag an "as noted" return that has more than a couple of comments and ask whether a resubmittal is the safer path.

A log is only useful if it matches what happened yesterday. A few habits do most of the work.

• Update at every transmittal. Log the date in when a package arrives and the date out when it leaves. Don't batch this to Friday.
• Log the resubmittal as a new revision of the same row. Keep the history. When a dispute comes up about who held the submittal, the dates answer it.
• Review the log weekly against the schedule. Sort by "Required by" and look at everything not yet returned.
• Flag the long-lead items first. If switchgear, elevators or curtain wall are late in the log, they are late on the schedule.
• Reconcile with the field. Before anything is installed, check that its row shows an approved status.

If you run many projects, a shared tracker beats per-job spreadsheets. Olumba tracks project documents in one place (pricing), and the FAQ covers related questions.

• Building the log from what subs send. You will miss the submittals nobody remembered. Start from the specs.
• One row for a whole spec section. Split by item. A single "Doors" row hides that the hardware set and the frames are on different timelines.
• No "required by" date. Without it you can't tell which late item matters.
• Mixing action and informational items in one transmittal when the spec forbids it.
• Letting "approved as noted" close the row without confirming the sub saw the notes.