The submittal review process looks straightforward on paper. Subcontractors prepare packages. The GC reviews them. Compliant submittals go to the design team for approval. Non-compliant ones come back with comments. The cycle repeats until everything is approved and procurement can begin.
In practice, the process is where a significant portion of project cost and schedule risk gets created. Industry data consistently puts first-round submittal rejection rates at 30 to 40% across commercial construction. Each rejection adds at least two weeks to the review cycle and delays procurement on whatever equipment is involved. On projects with 500 or more submittals, that math compounds quickly.
Most of those rejections trace back to a short list of recurring process failures on the contractor side, not random errors or careless subcontractors. Understanding the pattern is the first step toward breaking it.
Treating the GC review as a routing step rather than a technical obligation
The most consequential mistake contractors make during the submittal process is treating the GC’s preliminary review as an administrative pass-through rather than a genuine technical checkpoint.
Under AIA A201, the contractor’s obligation is to review each submittal for conformance with the contract documents before it reaches the architect or engineer. That obligation exists independently of what the design team will eventually catch. The GC review is supposed to be the first line of defense against non-compliant submittals, not a formality that buys time while the design team does the actual checking.
When contractors skip or compress this step, they transfer the technical screening responsibility to the design team by default. The result is predictable: rejection rates rise, the back-and-forth with the design team increases, and the GC loses credibility with the architect and owner on every project where the pattern holds. The EJCDC’s analysis of submittal review liability makes clear that both the contractor and the design professional carry distinct obligations in the review process, and that conflating them creates risk for both parties. A contractor who consistently forwards non-compliant submittals is not meeting the contractual standard regardless of what the design team ultimately catches.
Reviewing the obvious and skipping the granular
Even contractors who take the preliminary review seriously tend to do it unevenly. The visible, obvious items get checked. The granular technical characteristics do not.
A project engineer working through a 70-page mechanical submittal under startup-phase schedule pressure is going to confirm that the manufacturer is correct, verify that the model number matches the specification, and move on. What gets missed is the one line in a 40-page spec section requiring a specific refrigerant type, the efficiency rating buried in a performance table that falls just short of the specified minimum, or the coating specification for a corrosive environment that the product data sheet does not address.
These are not edge cases. They are the items that drive the majority of design team rejections on complex mechanical and electrical submittals, precisely because they require careful cross-referencing between the product data and the specification rather than a quick visual check. IRMI’s analysis of submittal review under AIA documents notes that the design professional’s review is limited to conformance with the design concept expressed in the contract documents, not a comprehensive technical audit of every specification requirement. Contractors who rely on the design team to catch granular non-compliance are misunderstanding where that responsibility sits.
The practical challenge is volume. A complex mechanical submittal can contain 60 or more individual technical characteristics that need to be verified against plans and specifications. Many project teams have turned to no exceptions taken stamp language to understand the boundaries of design team review, but the upstream question is whether the GC review caught what it should have before the package ever left the contractor’s desk.
Key stat: Industry data puts first-round submittal rejection rates at 30 to 40% across commercial construction. Each rejection adds at least two weeks to the review cycle. On a project with 500 submittals, a 35% rejection rate means roughly 175 items cycling back through review before procurement can begin.
Misreading what a favorable review stamp actually means
A common and costly misconception is treating a “no exceptions taken” stamp, or any equivalent favorable review response, as a blanket approval that transfers responsibility to the design team.
It does not. A “no exceptions taken” stamp means the architect or engineer reviewed the submittal and found it appears to conform with the design intent expressed in the contract documents. The contractor’s responsibilities for dimensions, quantities, field coordination, and means and methods remain fully intact. If a submitted product passes design team review but turns out to have been installed incorrectly, or if dimensions on a shop drawing are wrong in a way the architect was not obligated to verify, the contractor owns that problem regardless of what the stamp says.
This matters most when submittals are returned with conditional notes. A stamp that reads “no exceptions taken as noted” requires the contractor to act on those notes and confirm the correction before proceeding. In practice, many teams log the approval status, file the stamped submittal, and move forward without tracking whether the conditions were actually met. When the owner walks the project six months later and finds that an approved-as-noted product was installed without the noted correction, the stamp is not a defense. The record shows a condition that was never closed out.
Submitting before the GC has actually reviewed
A related failure is subcontractors submitting packages directly to the design team, bypassing the GC review entirely. This is more common than it should be on busy projects, particularly when schedule pressure is high and the sub is eager to get approval and start procurement.
Beyond the contractual problem, it creates a practical one: the design team receives a submittal the GC has not seen, reviews it, and returns it either approved or rejected. If it comes back rejected, the GC is now managing a rejection cycle on a submittal they never evaluated. If it comes back approved, the GC may discover later that the approved product does not coordinate with other trades or conflicts with a specification requirement that the architect was not looking for.
The GC review step is not bureaucratic sequencing. It exists because the GC has full visibility into trade coordination, specification requirements across all divisions, and the job-site conditions that product selection affects. Removing it from the process creates gaps that are expensive to close after the fact.
Treating submittal review as a startup-phase task rather than a schedule-management tool
The final pattern is positional: most teams treat submittal review as something that happens during mobilization, rather than as a direct driver of the procurement and installation schedule.
Long-lead mechanical and electrical equipment, chillers, air handling units, switchgear, and similar critical-path items, cannot be ordered until their submittals are approved. That means every week added to the review cycle on those items is a week subtracted from float on the critical path. A joint study by Autodesk and FMI found that bad project data cost the construction industry $88.69 billion in rework in a single year, with a significant share traced back to information failures in the early phases of projects, exactly the window when submittals are being reviewed and procurement decisions are being made.
Teams that manage this well sequence their submittals by schedule criticality from the start. Long-lead items get prioritized for early, thorough review. The GC review is treated as a genuine technical checkpoint, not a queue. Conditional approvals get tracked to closure. And the submittal log is maintained as a live project management tool, not a historical archive.
The rejection rate data is not random. It reflects what happens when teams treat submittal review as overhead rather than as the quality control function it actually is. Getting that framing right at the start of a project is one of the most reliable ways to protect the schedule that follows.
