The submittal log: what it tracks, and a template you can copy

By Adam Chandler, founder of Pangea · August 20, 2026

A submittal log is the running record of every submittal a project requires — shop drawings, product data, samples, certificates, closeout documents — and where each one currently stands. One row per required item, showing who owns it, when it went out for review, when it is due back, what the reviewer returned, and whether a resubmittal is still open. The general contractor normally keeps it, the design team reviews the items on it, and the whole project reads it, because it is the one page that answers "is the steel approved yet?" without a phone call.

It is also the document that quietly decides whether a job hits its dates. A submittal sitting on the wrong desk for three weeks does not look like a problem until the material with the twelve-week lead time cannot be released for fabrication.

What is a submittal log in construction?

A submittal is anything the contract documents require the contractor to send to the design team before the work is bought or built — a fabricator's shop drawings, a manufacturer's product data sheet, a brick sample, a test report, a warranty. The log is the tracking layer on top of all of them.

Specs divide submittals into two kinds, and the log should mark which is which. The University of Houston's master specification for submittal procedures (section 01 33 00, the number most master specs use) draws the line the standard way: action submittals require the architect's responsive action; informational submittals do not, though they can still be rejected for non-compliance. Action submittals hold up procurement. Informational submittals are the ones that quietly go missing until closeout.

The log exists because the count is large and the consequences are sequential. A mid-size commercial job carries hundreds of required submittals, each with its own reviewer, turnaround clock, and downstream fabrication date. Teams that skip it do not discover the gap until a subcontractor asks why their material was never released.

Submittal log vs submittal register vs submittal schedule

Three terms, frequently used as if they were one. The honest version: they describe three jobs the same spreadsheet usually does.

The schedule is often the one your contract actually names. The UH spec requires a schedule of submittals in chronological order by the dates the construction schedule needs them, coordinated with the subcontracts and the schedule of values, including time for review, ordering, fabrication, delivery — and time for making corrections and re-reviewing anything the architect sends back. That last clause is the one people skip, and it is why so many submittal schedules quietly assume a clean first-pass approval.

Who maintains the submittal log?

The general contractor, in almost every delivery method — usually delegated to a project engineer or project coordinator who chases subcontractors for their packages, checks them before they go out, transmits them, and records what comes back. The architect and their consultants review and return; the owner's representative often keeps a parallel copy of long-lead and owner-furnished items.

The role split matters less than the copy split. When three parties each maintain "the" submittal log, the version people argue from is whichever one is open on the screen. Pick one master, say whose it is, and make everyone else read it rather than rebuild it.

What columns does a submittal log need?

Fifteen columns cover almost every project. Anything beyond is preference; anything short of it eventually produces an argument:

1. Submittal number — a unique, sortable ID. See the numbering convention below.
2. Specification section — the section that requires the item, so the log sorts the way the project manual reads.
3. Description — plain language: "structural steel shop drawings," not "per 051200."
4. Type — shop drawing, product data, sample, mock-up, test report, certificate, O&M, warranty.
5. Category — action or informational.
6. Responsible party — the subcontractor or supplier who owes the package.
7. Reviewer — architect, structural engineer, MEP engineer, or the consultant the item routes to.
8. Date required — the date the schedule needs this approved by, working backward from fabrication.
9. Date received from sub — when the contractor got it, which is where most of the lost time hides.
10. Date sent for review — the date the review clock starts.
11. Date due back — sent date plus the review allowance in your spec.
12. Date returned — actual.
13. Stamp action — approved, approved as noted, revise and resubmit, rejected, reviewed.
14. Revision — 0 for the first pass, then A, B, C for resubmittals.
15. Ball in court — who is holding it right now. If you keep only one status column, keep this one.

Two more earn their space on jobs with real procurement risk: lead time in weeks from release to delivery, and notes — the one-line reason a rejection happened, so the resubmittal does not repeat it.

Submittal log template

Paste this header row into a spreadsheet and you have the log:

Submittal no. | Spec section | Description | Type | Action/Info | Responsible sub | Reviewer | Date required | Received from sub | Sent for review | Due back | Returned | Stamp action | Rev | Ball in court | Lead time (wks) | Notes

For numbering, borrow the convention the master specs already use: the specification section number, a decimal point, then a sequential number — so the first submittal under section 06 10 00 is 061000.01, and resubmittals add an alphabetic suffix after another decimal point (061000.01.A). The ID then tells you where the item lives in the project manual without opening anything, and sorting the log sorts it by trade.

One habit separates a log people use from one they avoid: never delete a row. Supersede it with a resubmittal row, because the history of a rejected submittal is exactly what gets asked about later.

What do the submittal review stamp codes mean?

Codes vary by firm and by spec, and the stamp legend printed on the returned document governs — but the family is consistent, and the distinction between the middle two is where money gets lost:

• Approved / No exceptions taken — proceed as submitted.
• Approved as noted / Make corrections noted — proceed, but the marked corrections are binding and must be incorporated. Not the same thing as "no exceptions taken," and treating it as the same is how a fabricator builds the version that was corrected.
• Revise and resubmit — do not proceed. Fix and send it back through the full review cycle, which costs another review window.
• Rejected — the submitted product or approach does not comply. Usually means a different product, not a redrawn one.
• Reviewed / For information only — the informational category. No action expected, but non-compliance can still be called out.

Most stamps also carry a disclaimer limiting the reviewer's action to conformance with the design intent and leaving dimensions, quantities, and field fit with the contractor. That language is doing real work — worth reading once, rather than assuming an approval transfers risk it does not.

How long should submittal review take?

Whatever your specification says — and it is worth reading the number rather than assuming it. The UH master specification allows 15 days for initial review of each submittal and a further 15 for each resubmittal, with review time starting on the reviewer's receipt rather than the date the contractor sent it. Federal and many municipal specs use 14 calendar days.

The corollary surprises contractors: many specs state plainly that no extension of contract time will be authorized because the contractor failed to transmit submittals far enough in advance to allow for processing, including resubmittals. The review allowance is the reviewer's protection, not the contractor's float — which is why the "due back" column should be computed from your actual spec, and "date required" worked backward from fabrication with a resubmittal cycle built in.

The first packages also come due sooner than teams expect. Specs commonly require the submittal schedule and the earliest submittals within the first weeks after the notice to proceed, which means the register gets built out of the specs while mobilization is still happening.

How do you keep the submittal log current?

Every submittal log starts accurate. The question is whether it is still accurate in month seven. Four habits do most of the work:

• Review it as a standing agenda item in the weekly progress or OAC meeting — filtered to overdue and ball-in-court, not read line by line. Fifteen rows discussed beats four hundred skimmed.
• Capture verbal approvals the same day. "We're fine with the alternate fixture," said in a coordination call, is a real decision that never reaches the log unless someone writes it down — and it is the kind of thing disputed six months later.
• Update on transmittal, not on Friday. A log updated in a weekly batch is wrong six days out of seven, including the day someone makes a purchase decision from it.
• Reconcile against the register quarterly. Items nobody ever transmitted are invisible by definition; comparing the log back to the required-items list is the only way to find them.

The underlying problem is not laziness — it is that project facts surface in whatever meeting or inbox they happened to land in, and someone has to carry them to the document where they belong. The FMI and PlanGrid Construction Disconnected study put a number on the general version of this: construction professionals spend roughly 5.5 hours a week just looking for project data, and poor data and miscommunication cost US construction around $177 billion a year in labor.

Where Pangea fits

Straight answer first: Pangea is not submittal management software and will not stamp a shop drawing. It is an AI notetaker and project coordinator for architecture, engineering, and land-development firms, and its job here is upstream of the log — making sure what gets said about submittals in meetings actually reaches the person keeping it.

It records your coordination and progress meetings, including in-person ones with a phone on the table and no bot joining the call, and writes structured minutes filed to the project rather than the date. Action items come out of what was said — "Kim is revising the outlet structure, resubmittal Friday" becomes a tracked item with a receipt back to the moment it was said — and with your approval those updates can be pushed into the project management software your firm already runs, so the log's owner works from a list instead of a memory. Asking the project a question returns an answer citing the meeting it came from, which settles "when did they say that was approved?" faster than scrolling a thread. If the chasing and filing is what eats your week, that is the case we make on our project coordinator page. There is a 14-day free trial, no credit card required.

Frequently asked questions