The construction submittal process is the contractual gate every material and method has to pass through before you can fabricate, order, or install it. The single action that protects your schedule: build a complete, spec-referenced submittal package tied to a project's submittal schedule, and get it in front of the GC before you commit to a long-lead order.
TL;DR:
- The review process relies heavily on a thorough initial submittal schedule based on actual installation dates to prevent schedule delays caused by long-lead items.
- Properly assembled submittal packages must include accurate spec references, clearly marked product data, and relevant certifications to avoid common rejections.
- In small teams, assigning one person as the owner of the submittal log and using a standardized checklist improves consistency and reduces schedule slippage.
- The GC’s preliminary review is the most critical step for catching issues early, saving time and reducing design-team rejections.
- Prioritizing high-risk, long-lead submittals and maintaining detailed documentation helps manage schedule risk and supports dispute resolution if delays occur.
Table of Contents
- What Is a Construction Submittal, and Why Does It Carry Contractual Weight?
- What Are the Main Types of Construction Submittals?
- How Does the Submittal Approval Process Actually Work, Step by Step?
- Who Owns What in the Submittal Review Chain?
- Why Do Submittals Get Rejected, and How Do You Fix It?
- What Templates and Tools Do You Need to Run This Well?
- How Should Small Trade Teams Staff and Time-Budget Submittals?
- How Do You Communicate During Reviews to Resolve Issues Fast?
- How Do You Handle Urgent or Expedited Submittals?
- How Do You Manage the Risk of Submittal Delays and Errors?
- What Training and Documentation Should Your Team Have in Place?
- What Actually Moves the Needle on Submittal Approvals?
- How Can Software Simplify Submittal Tracking for Trade Subs?
- Where Can You Learn More About the Submittal Process?
- Sources
What Is a Construction Submittal, and Why Does It Carry Contractual Weight?
A submittal is a document, drawing, sample, or mock-up you send for review to prove your proposed material or method actually matches what the contract requires. That covers shop drawings, product data, samples, mockups, and test reports, and each one exists to answer a single question: does this match the spec, or doesn't it?
The stakes are contractual, not clerical. Most commercial contracts, especially anything following AIA conventions, treat an unapproved submittal as a stop sign. Order the gear before approval and you own the risk if it gets rejected. That risk shows up as re-fabrication costs, blown lead times, and a GC who now trusts your paperwork a little less.
Reviewers respond to a submittal with one of four dispositions: Approved, Approved as Noted, Revise and Resubmit, or Rejected. Only the first two clear you to move forward without changes. A "revise and resubmit" sends the whole package back through the submittal review cycle, which can easily cost you several weeks depending on how backed up the design team is.
Here's the myth worth killing early: there's no universal fixed-length review clock. AIA A201 doesn't mandate a fixed turnaround. Review timing is governed by the project's own submittal schedule, and when no schedule exists, the architect uses professional judgment on timing. If your contract doesn't spell out review windows, don't assume two weeks. Ask, and get it in writing.
What Are the Main Types of Construction Submittals?
Every trade submits some mix of the same core categories, but what counts as "complete" changes by trade. Reviewers reject packages fastest when the documentation doesn't map cleanly to the spec section it's supposed to prove.
- Shop drawings: fabrication-level detail, dimensions, and coordination notes showing how your work interfaces with adjacent trades, not just a manufacturer's stock drawing with your job number written on it.
- Product data (cut sheets): manufacturer literature marked up to show the exact model, size, and options you're providing, with the applicable spec section circled or noted directly on the page.
- Samples and mockups: physical material samples or built mockups with documented acceptance criteria, often signed off in person rather than by paper review alone.
- Test reports and certifications: third-party verification that a product meets a code or performance standard, especially for fire-rated assemblies, structural connections, or life-safety equipment.
- Long-lead and fabrication submittals: items with extended manufacturing timelines that need approval locked in months, not weeks, before the install date.
Trade-specific expectations vary sharply. Electrical subs typically need fixture schedules and photometric layouts that match the lighting design intent. Plumbing packages usually hinge on fixture rough-in dimensions and trim specifications lining up with the architectural plan. HVAC submittals almost always require capacity and efficiency data, often cross-checked against AHRI certified ratings. Masonry work depends heavily on a physical sample panel and a documented mortar mix design, something covered in more detail in this breakdown of shop drawings for masonry submittals.
How Does the Submittal Approval Process Actually Work, Step by Step?
The workflow has a rhythm to it once you've run it a few times, but the sequence matters more than most subs realize. Skip a step, and you're not saving time, you're borrowing it from three weeks in the future.
- Build the submittal schedule during preconstruction. Work backward from your need-by install dates, add fabrication lead time, then add review time for both the GC and the design team. This schedule, built around actual installation dates, is your single best protection against getting caught by a late long-lead order.
- Assemble the package. Every submittal needs a transmittal cover sheet stating exactly what action you're requesting, the spec section it responds to, marked-up product data, required certifications, and a compliance matrix if the spec calls for one.
- Send it to the GC for preliminary review. This is the checkpoint most subs underestimate. The GC's stamp isn't a formality. It confirms the spec section is correctly referenced, the package is complete, required certs are attached, and revisions match the current contract documents.
- Design-team technical review. The architect or engineer checks the submittal against design intent and code compliance. This is where most of the real review time gets spent, and where your disposition comes back.
- Handle the disposition. "Approved" or "Approved as Noted" means you're clear to proceed, sometimes with minor field adjustments. "Revise and Resubmit" or "Rejected" sends you back to step 2, and the clock resets.
- Resubmit if needed, with version control. Increment the revision number, log what changed, and reference the prior submittal number in your transmittal so reviewers aren't hunting for context.
- Issue the purchase order only after approval. This is the line that separates disciplined subs from the ones eating change orders. Ordering ahead of approval to "save time" is the single most common way a submittal delay turns into a fabrication delay.
The GC's preliminary review is where the real leverage sits. When a GC actually runs a thorough pre-review, design-team rejections drop noticeably, because half the paperwork problems get caught before an architect ever opens the file. If your GC's review process feels loose, that's worth raising directly, because a sloppy pre-review on their end becomes your resubmittal cycle.
Pro Tip: Name your submittal files with the spec section number first, then a short description, then the revision letter (like "26 05 00 Panelboards Rev A"). Reviewers scanning a shared folder full of generic "Submittal_Final_v2.pdf" files will lose time, and some of that lost time becomes your delay.
Resubmittal mechanics deserve their own attention because this is where projects quietly bleed weeks. Track every submittal in a log with a unique number that never changes across revisions, only the revision letter increments. Note who's responsible for the next action at every point in the cycle. And keep every transmittal, comment sheet, and revision on file. If a schedule dispute ever comes up, that paper trail is what proves you submitted on time and the delay sat with someone else's desk, not yours.
Who Owns What in the Submittal Review Chain?
Ambiguity about who's responsible for which check is what causes the same mistake to repeat project after project. Four parties touch every submittal, and each one has a distinct job.
- Subcontractor: owns accuracy of the submitted data, field verification of existing conditions, and clear justification any time you're proposing a substitution or "or equal" product.
- General contractor: owns the master submittal schedule, runs the preliminary completeness review, and coordinates overlapping submittals between trades so conflicts surface before installation, not after.
- Design team (architect/engineer): reviews for design intent and code conformance, with discipline-specific reviewers (structural, mechanical, electrical engineers) handling the technical detail within their scope.
- Manufacturer or vendor: supplies accurate product data, test reports, and certifications, and stands behind that documentation if a product fails to perform as represented.
Coordination failures happen most often at the seams between trades. A classic example: an HVAC sub submits ductwork shop drawings showing a routing path that runs directly through a structural beam location the steel sub already had approved. Neither submittal was wrong on its own. The GC's coordination review is supposed to catch exactly that kind of conflict before either trade starts fabrication, which is one reason a clear roles framework with your GC pays off more than most subs expect going in.
Why Do Submittals Get Rejected, and How Do You Fix It?
Most rejections trace back to a small handful of preventable mistakes. Missing documentation, wrong spec references, and unmarked or unclear cut sheets cause the majority of first-pass failures, not actual product deficiencies.
- Missing documents: build a standing checklist per submittal type so a cert or test report never gets forgotten because someone assumed the vendor included it.
- Wrong or missing spec references: cite the exact spec section and paragraph number on the transmittal, not just "electrical" or "HVAC."
- Unmarked cut sheets: circle or highlight the specific model, size, and option on manufacturer literature; never submit an entire 40-page catalog and expect the reviewer to find your item.
- Substitution documentation gaps: for any "or equal" product, attach a side-by-side comparison against the specified item, not just a claim that it performs similarly.
- Coordination conflicts: group related submittals from different trades together when they touch the same physical space, so conflicts surface at review instead of on the job site.
Before anything leaves your office, run a pre-review completeness check: confirm the spec section tie, confirm the GC's stamp field is ready to be filled, confirm every required cert is attached, and confirm you're submitting the current drawing revision, not an outdated one someone pulled from an old folder.
Pro Tip: When a submittal comes back "Revise and Resubmit," respond to every single reviewer comment individually in your resubmittal cover letter, even the ones you disagree with. Silence on a comment reads as an oversight, and that's often what triggers a second round of rejection on an otherwise-fixed package.
What Templates and Tools Do You Need to Run This Well?
You don't need enterprise software to run a clean submittal process, but you do need three specific artifacts, and most small trade offices are missing at least one of them.
A minimal submittal log needs to track:
| Field | Why It Matters |
|---|---|
| Submittal number | Unique tracking ID that stays constant across all revisions |
| Spec section | Ties the submittal to the exact contract requirement it satisfies |
| Item description | Lets anyone scanning the log identify the submittal without opening the file |
| Responsible party | Names who owns the next action, so nothing stalls waiting on an unclear handoff |
| Submit date | Anchors the timeline for schedule and claims purposes |
| Expected review window | Sets a follow-up trigger before the item becomes a schedule risk |
| Status | Shows disposition at a glance: pending, approved, revise, rejected |
| Need-by date | Connects the submittal directly to the procurement and install schedule |
Your transmittal template should state the requested action plainly (approval, information only, distribution), reference the spec section, and list every attachment by name so nothing gets lost in transit.
A one-page pre-submission checklist catches the five items that cause most rejections: spec reference, marked cut sheet, required certs, current revision, and complete compliance matrix.
Once something's approved, publish it somewhere the whole project team can see it. Field crews installing from a superseded version is a common and entirely preventable error, and it usually traces back to an approved PDF that never made it out of someone's email inbox. A tool built for trade contractor workflows handles that publishing step automatically, which matters more once you're running more than a handful of active submittals at once.
How Should Small Trade Teams Staff and Time-Budget Submittals?
On a 3 to 15 person shop, submittals usually fall on whoever's already managing the job, which means they get squeezed between site visits and change order paperwork. That's a mistake worth fixing early.
Assign one person as the register owner, even if it's a part-time responsibility layered onto an office manager's existing role. That person tracks status, flags approaching need-by dates, and chases vendors for missing documentation. Someone else, often the PM or estimator, assembles the actual technical package since they understand the spec and scope best.
Budget your time realistically. A straightforward product data submittal with clean vendor cut sheets might take 30 to 45 minutes to assemble. A coordinated shop drawing package spanning multiple sheets and requiring field verification can run several hours, especially the first time you're working with a new manufacturer's drawing format. Batch long-lead items early. If a piece of equipment has a 12-week fabrication window, that submittal needs to hit the GC's desk well before you'd normally think about ordering, not after.
Small teams that assign one person clear ownership of the register and use a standing pre-submission checklist consistently see fewer rejections and less schedule slippage than teams handling submittals ad hoc between other jobs. The fix isn't more staff. It's one clear owner and a repeatable checklist that doesn't live only in someone's head.
How Do You Communicate During Reviews to Resolve Issues Fast?
Set the communication protocol before the first submittal goes out, not after the first one stalls. Agree with the GC upfront on the preferred channel for status questions, whether that's a shared log, email, or a project management platform, and stick to it so nothing gets buried in someone's inbox.
Follow up proactively, not reactively. If a submittal hasn't moved in a week beyond its expected review window, send a short, specific status check referencing the submittal number and need-by date rather than a vague "just checking in." Specificity gets a faster answer because the person on the other end doesn't have to go dig up context first.
When a reviewer's comment is unclear, ask for clarification immediately instead of guessing and resubmitting something that misses the actual concern. A single clarifying phone call often saves an entire resubmittal cycle. Keep every clarification in writing afterward, even if the original conversation happened by phone, so the resolution is documented.
Escalate early when a submittal is genuinely at risk of blowing a need-by date. Loop in your PM and the GC's project engineer directly rather than letting the log silently show a red flag nobody's acting on. Waiting to escalate almost always costs more schedule time than the escalation conversation itself.
How Do You Handle Urgent or Expedited Submittals?
Every project eventually has one: a submittal that has to move faster than the normal review window allows, usually because a change order or a field condition compressed the schedule after the fact.
Flag it explicitly on the transmittal. Don't bury an urgent request inside a routine cover sheet and hope someone notices the deadline. State the need-by date clearly and explain briefly why the timeline compressed.
Call ahead before you send it. A short heads-up call to the GC's project engineer, and through them to the design team, sets the expectation that this one needs priority handling. Reviewers move faster for a request they were warned about than one that shows up cold in a queue of twenty others.
Submit the cleanest possible package. Expedited review is exactly the wrong moment to send something incomplete, because there's no time buffer left to absorb a rejection and rework. Have someone else on your team proofread the compliance matrix and spec references before it goes out.
Accept that expediting has limits. A design team can compress their internal review time somewhat, but they generally can't rush a legitimate code or design-intent concern just because your schedule got tight. Building slack into your original submittal schedule is still the better fix than relying on expediting as a routine strategy.
How Do You Manage the Risk of Submittal Delays and Errors?
Treat submittal risk the same way you'd treat any other schedule risk on the job. Identify it early, assign ownership, and build in buffer where the consequences of a miss are highest.
Prioritize by consequence, not by convenience. A long-lead switchgear submittal carries far more schedule risk than a routine paint color submittal, so it should get reviewed, tracked, and followed up on first, even though it's often more paperwork to assemble.
Keep a documentation trail for every submittal, approved or not. If a delay ever turns into a claim or a change order dispute, your transmittals, dated logs, and written responses to reviewer comments are what prove where the responsibility actually sat.
Build schedule float around your longest-lead items specifically. A generic two-week buffer across the whole project doesn't protect you the way a targeted 30-day buffer on your slowest-fabricating equipment does.
Review your submittal log weekly, not monthly. A submittal that's quietly overdue by three weeks is a much bigger problem than one that's overdue by three days and caught immediately. Weekly review is what keeps small delays from compounding into schedule-threatening ones.
What Training and Documentation Should Your Team Have in Place?
Every person who touches a submittal, whether that's an estimator pulling spec sections or an office manager sending transmittals, should know the disposition categories, the escalation path, and where the log lives without having to ask.
Write down your submittal process once, clearly, and keep it somewhere every new hire can find it. A one-page internal procedure covering package assembly, transmittal format, and log update responsibilities prevents the knowledge from living only in one person's head, which becomes a real problem the moment that person is out sick during a critical review window.
Train new estimators and PMs on reading spec sections specifically for submittal requirements, not just for pricing. Specs often bury submittal-specific requirements, like required certifications or sample sizes, in sections that don't obviously look submittal-related at first glance.
Document every rejection and its cause internally, even informally. Over a handful of projects, a pattern usually emerges, maybe your team consistently misses a particular certification type, or a specific vendor's cut sheets never come pre-marked the way reviewers expect. That internal record turns into your best training material for the next new hire.
What Actually Moves the Needle on Submittal Approvals?
Most advice on this topic treats every submittal like it carries equal risk, and that's the biggest thing conventional guidance gets wrong. A paint color submittal and a custom switchgear submittal carry very different levels of schedule risk, and treating them identically wastes attention on the low-stakes items while the genuinely dangerous ones drift.
The conventional fix everyone reaches for is more software, more automation, more dashboards. Useful, but secondary. The evidence points somewhere plainer: the GC's preliminary review is the highest-leverage checkpoint in the entire chain, and most subs have zero visibility into how rigorously their GC actually runs it. If you've never asked your GC what their pre-review checklist looks like, that's worth a five-minute conversation before your next bid.
Prioritize the boring stuff first. One person owning the register. A one-page pre-submission checklist. Spec references written out in full on every transmittal. None of that is exciting, and none of it requires a platform purchase to start doing tomorrow. The trade shops with clean first-pass approval rates aren't the ones with the fanciest tools. They're the ones where nobody has to guess who's responsible for the next step.
— Dave
How Can Software Simplify Submittal Tracking for Trade Subs?
Everything covered here, the register, transmittal history, version control, and need-by date tracking, is exactly what gets messy fast once you're juggling more than a handful of active submittals across two or three jobs. A spreadsheet works until it doesn't, usually right around the time two people are editing it at once and someone overwrites a status update.
There is software that replaces spreadsheets with a single submittal register designed for trade subcontractors: with automatic transmittal history logging, version tracking to prevent superseded drawings, and status alerts tied to need-by dates instead of calendar reminders. This software can connect to job costing and QuickBooks syncing tools, allowing submittal status to sit alongside the job data project managers typically check.
One honest note: no software replaces reading the actual contract specs. Validate every submittal requirement against your spec book before you commit to an order, always. If you want to see how the register and templates work on a real project, you can start a free trial and pull your first submittal log together the same day.
Where Can You Learn More About the Submittal Process?
A few sources back up the core guidance here and are worth bookmarking directly:
- Submittal Review Process: Roles, Steps, and Issues breaks down the review chain and the AIA timing myth.
- Construction Submittals: Ultimate Guide and Template offers a downloadable log template structure.
- For trade-specific detail, see Subascent's guides on shop drawings for masonry submittals and document version control.
- For preconstruction coordination, qualifying subcontractors before project start is a useful companion read.
Sources
- Submittal Review Process: Roles, Steps, and Issues | Datagrid
- Construction Submittals – Ultimate Guide and Template - Autodesk