How to Review a Submittal: A PM’s Essential Step-by-Step Checklist

79

Learning how to review a submittal comes down to one job. As the contractor, you make a first-pass check of the submittal package before it goes up to the engineer or architect. You confirm the package is complete and that the product matches the specs and the drawings, so you catch problems on your desk instead of after the engineer sends it back.

This article is for the GC-side PM or project engineer who has a submittal package open right now and needs to check it before routing it up. If you’re not sure what a submittal is in the first place, start with cut sheet vs submittal. This one is about how to review a submittal you’ve already been handed.

This article covers:

• How to get oriented on a submittal before you check it
• The completeness check
• How to verify the product data against the spec
• The coordination check against other trades and the current drawing revision
• How to log the review and route it up
• A downloadable submittal review checklist
• Common mistakes I’ve seen on real jobs

Here’s the short version.

Here’s how to review a submittal:

1. Review the submittal. Understand what it includes and what you’ll need to compare it against in the plans and specs.
2. Pull up the plans and specifications and go to the section most relevant to your submittal.
3. Check that the required information in the submittal matches the project documents.
4. Decide where it goes next. If the submittal covers what the plans and specs require, prepare it to send to the GC, engineer, or CM for their review and approval. If not, send it back to the vendor for correction.
5. Log it. Once you’ve sent the submittal out for review, log it in the submittal log for future reference.

That’s the short version, and it is short on purpose. Each of these steps has more going on under it than one line can hold, and the rest of this article walks through the parts that actually take judgment. Here’s how to review a submittal on a real job, step by step.

Know What You’re Looking At

When a submittal lands on my desk, the first thing I do is open it and figure out what it actually is. Is it a cut sheet for a single piece of equipment? Shop drawings? A certification or a test report? A full package with several of those bundled together?

That first read isn’t the real review. It’s just orientation. I’m getting a feel for what the vendor or contractor handed me, so I know where I need to look in the plans and specs to compare against.

Once I know what the submittal covers, I know where to go in the project documents. A cut sheet for an RTU sends me to the mechanical equipment schedule. A structural connection detail sends me to the structural drawings and that spec section. The submittal itself tells you which part of the plans and specs you’re about to need.

So the order is:

• Read the submittal first. Understand what it is and what it’s claiming.
• Then pull the plans and specs, specifically the section that matches what the submittal covers.

Now you’ve got both sides in front of you: what the vendor is proposing, and what the project actually called for.

Here’s what that looks like on a real one. Say a vendor sends me a submittal for an air handler we’re about to order. First thing, I pull the drawings and find that unit in the equipment schedule. Then I go down the row and check the values that matter:

• Power. Voltage, phase, the electrical the unit needs.
• Cooling. Sensible cooling and total cooling, both.
• Coil. Number of rows on the coil.
• Any notes. Whatever else the schedule calls out for that unit.

Then I go to the specifications and look for anything the engineer is calling for. Some of this overlaps with the schedule, but the spec is where the full requirements live. It might call for a special coating on the casing and the coil, a specific filter type, or other add options. Some of those show up in the equipment schedule too, some only in the spec. Either way, if it’s required, it has to be in that submittal when it goes up to the engineer.

That’s the whole point of checking both the drawings and the specs. The drawings give you the performance numbers. The specs confirm the full scope, including the options that the schedule might not list. Miss the spec and you can approve a unit that hits every number in the schedule and still isn’t what the engineer asked for.

A quick note on the specs. The spec section does more than describe the product. It also lists the submittal requirements, meaning what the vendor was supposed to send in the first place. Performance data, dimensions, certifications, whatever that section requires. That list is your completeness check, and it’s the next step.

For more on how cut sheets fit into all this, see cut sheets in construction.

One thing to confirm before you go further: make sure you’re looking at the current drawing revision. If the design has been revised and you’re checking a submittal against an old equipment schedule, you can approve something that matched the old design and conflicts with the new one. More on that in the coordination check.

The Completeness Check

Before I check whether the product is right, I check whether the package is complete. These are two different jobs and it’s worth doing them in that order. No point verifying capacities and electrical on a submittal that’s missing half the documents it was supposed to include.

Completeness is simple: did the vendor or contractor send everything the spec section requires?

That’s why you pulled the spec in the last step. You have to read through the spec section to see exactly what the engineer wants submitted. Most sections spell out the required submittals somewhere in the section text, and for a piece of equipment that list usually includes things like:

• Product data. The cut sheet or manufacturer’s data sheet for the unit.
• Performance data. The capacities, ratings, and curves the spec asks for.
• Dimensions. Physical size, clearances, weights.
• Electrical data. Voltage, phase, full load amps, anything the spec requires.
• Certifications or listings. AHRI, UL, whatever that section calls out.
• Any required options. The special coatings, filters, or add-ons we talked about in the last step.

Run down that list and confirm each item is actually in the package. If the spec asks for six things and the vendor sent four, the review stops here. It goes back to the vendor for the missing two before it goes anywhere else.

This is the cheapest catch on the whole project. It takes a few minutes and it saves you from sending an incomplete package up to the engineer, who sends it back, which adds a full review cycle to your schedule for no reason.

I’ve had submittals come back for just a few missing items, and the reviewer had taken months to even perform the first review. So now you’re waiting all that time only to find out a couple things were missing, you fix them, and you go back into the queue. That one delayed the project by quite a bit, and it was completely avoidable. A ten-minute completeness check on my end would have caught what they flagged.

One thing completeness does not mean: it doesn’t mean the product is correct. A package can have every required document and still propose the wrong unit. Completeness just gets you to the point where you have everything you need to actually check the product against the spec. That check is next.

Does the Product Data Actually Meet the Spec?

This is the real review. The package is complete, so now you check whether the product the vendor proposed actually matches what the project requires.

You’re comparing two things side by side: the submittal against the plans and specs. Go down the requirements and confirm each one. For an equipment submittal, that’s where the cut sheet review lives. I covered the mechanics of reading a cut sheet in cut sheet vs submittal, so here I’ll focus on the comparison itself.

Working through that air handler example, I’m checking the submitted unit against the schedule and the spec on:

• Capacity. Sensible and total cooling have to meet or exceed what the schedule calls for.
• Electrical. Voltage and phase have to match. This is the one that bites people. A unit that needs a different voltage than the design means electrical rework or a new selection.
• Physical fit. Dimensions and weight against the space and structure available.
• Coil and configuration. Number of rows, airflow, anything the schedule specified.
• The spec extras. The coatings, filters, and options the spec called for. Confirm they’re actually built into the unit being submitted, not just mentioned.

One thing on the electrical that’s easy to miss: don’t just check the unit’s power requirements against the mechanical schedule. Cross-check them against the electrical plans too. Breaker sizing, MOP, the panel the unit is fed from. I can’t tell you how many times I’ve found the power requirements in the mechanical plans not matching the electrical side.

Here’s one that paid off. An engineer had flipped the labeling on an indoor and outdoor unit on the electrical distribution panel, and on top of that used the wrong MOP values. The electrical sub didn’t catch it, even after I sent an email flagging the discrepancy. When it came time to install and they put in the wrong breaker, I had written proof that I’d notified them. They ate the cost to swap it for the correct breaker for our equipment.

Two lessons in that one. First, the mechanical and electrical sides have to agree, and the only way you know is to check both. Second, when you spot something, put it in writing. That email is the difference between you eating a cost and the responsible party eating it.

If everything lines up, the product side of the review is done. If something’s off, you’ve got a decision to make, and which way you go depends on what’s off.

If the vendor just submitted the wrong thing, it goes back to them to correct and resubmit. They pulled the wrong model, they missed an option, they sent the 460V unit when the job is 208V. That’s a vendor fix. You don’t route a submittal up the chain knowing it doesn’t match.

If the product can’t meet the spec as written, that’s a different problem, and it’s bigger than a resubmit. Sometimes the spec calls for something the available equipment genuinely can’t deliver. That’s when you’re looking at a variance, an RFI, or both, to get the design intent sorted out before anything gets ordered.

Here’s a real one. I was on a military project where the spec for a pump called for a set of requirements the manufacturer flat out could not meet. They told us they weren’t even sure equipment existed that could hit everything the spec was written for. So we weren’t dealing with a wrong-model resubmit. We were dealing with a spec that may have been impossible as written. That kicked off a variance and a string of RFIs, and the whole thing turned into an ordeal just to get the pump approved and on order. It delayed our equipment by a few months.

The lesson from that one: when a submittal doesn’t match, figure out why before you decide what to do with it. A wrong model is a five-minute email to the vendor. A spec the market can’t satisfy is a design conversation that needs an RFI and time built into the schedule. Reading them the same way costs you either accuracy or weeks.

The Coordination Check

Completeness and product data are about the submittal on its own. Coordination is about how that submittal fits with everything else on the job. This is the step that separates a PM’s review from a vendor just checking their own paperwork.

Two things to check here.

First, the current drawing revision. I flagged this earlier and it matters enough to repeat. Confirm you’re reviewing the submittal against the latest set, not an old one. Designs get revised mid-project. If the equipment schedule changed in a revision and you’re checking against the old numbers, you can approve a unit that matched the old design and conflicts with the current one. Always verify the revision date on the drawings you’re comparing against before you sign off.

Second, coordination with the other trades. Your equipment doesn’t live in a vacuum. It connects to other systems, sits in shared space, and gets fed by other trades’ work. The submittal has to work with all of it.

For an HVAC unit, that means checking things like:

• Electrical. The breaker, the MOP, the panel feeding the unit, all matching between the mechanical and electrical plans. This is where that flipped-label, wrong-breaker story came from. The mechanical and electrical sides have to agree, and you’re often the only one checking both.
• Weight. Confirm the weight of the submitted unit matches the weight in the design drawings. If they match, the structural side was already accounted for by the engineer. If the submitted unit is heavier than what the design assumed, flag it, because that’s a change the structural engineer needs to review. Verifying the structure itself is sufficient isn’t on you. Confirming the weight matches the design is.
• Space and clearances. Will the unit physically fit where it’s supposed to go, with the service clearances the manufacturer requires? Other trades may have equipment in the same space.
• Connections. Piping, ductwork, controls. The connection points on the submitted unit need to match what the other trades are roughing in.

This is also where the submittal earns its keep across the whole job. Once you have it, that one document feeds every trade that has to work around your equipment:

• Retrofit fit. On a retrofit, the submittal tells you whether the new unit will actually work in the existing space before anything shows up on a truck.
• Electrical sizing. The electrical contractor needs your submittal to size their breakers correctly and confirm there are no discrepancies when they make their own selections.
• Sheet metal. It tells the sheet metal crew the size of the duct connections.
• Pipe fitters. It gives them the connections for chilled water, drain, and reheat if you’ve got it.
• Supports and isolation. You’ll know how to size the concrete pad if one’s needed, or what size spring isolators to order if the unit requires them.

There’s a lot of value in knowing what to pull from your submittal. It’s not just a document you check and forward. It’s the source the rest of the trades build their work around.

You won’t catch every cross-trade conflict from your desk. But the obvious ones, the ones that show up when you actually compare the mechanical submittal against the electrical plans and the structural drawings, those you can catch before they become field problems.

This is also where shop drawings vs construction drawings matters. The submittal might include shop drawings from the subcontractor. On the mechanical side, that’s the mechanical contractor showing how they plan to lay out and install their work. Those shop drawings have to coordinate with the construction drawings the rest of the job is working from.

The coordination check is the part that takes experience. A new PM can run a completeness check off a list. Knowing which cross-trade conflicts are likely on a given job, and where to look for them, comes from having seen them go wrong before.

Log It and Route It Up

Your review is done. The package is complete, the product matches the spec, and you’ve checked coordination. Two things left: log it, then send it up.

Log it first. Open your submittal log and record the review. At minimum you want the submittal number, the date you reviewed it, what it’s for, and where it’s going next. If you don’t have a log going yet, this is the document that keeps the whole submittal process from turning into a pile of loose PDFs and forgotten email threads. I built a free one you can grab in the submittal log template post.

The log matters for the same reason that email in the breaker story mattered. It’s your record. It’s also what surfaces the problems in the first place. Scanning the log is how you catch that a submittal has been sitting in review for six weeks, or that something’s overdue and holding up an order. Without the log, those things slip until someone downstream is asking why the equipment isn’t here yet. With it, you’re the one raising the flag.

Then route it up with a cover sheet or transmittal. The submittal goes to the next reviewer in the chain. Depending on the job, that’s the GC, the construction manager, the architect, or the engineer, and sometimes more than one in sequence. You don’t just forward the file. You send it with a cover document that records what you sent, when you sent it, and who it went to. Often that’s a transmittal. On government jobs there’s usually a specific transmittal form you’re required to use, and in other cases a submittal cover sheet does the same job.

Whatever form it takes, the cover document does two things. It tells the reviewer what they’re looking at, and it creates a record that you sent it on a specific date. That date matters. If the submittal sits in review too long and starts affecting your schedule, that record is your proof of when the clock started.

One thing I’ll keep short, because it has its own explanation elsewhere: when the submittal comes back, it’ll come back with a response. Approved, approved as noted, revise and resubmit, or rejected. Each one tells you what happens next, and you log that response when it lands. If a reviewer’s comment doesn’t make sense or seems wrong, that’s what an RFI is for.

That closes the loop on your end. You reviewed it, logged it, routed it up, and recorded what came back.

How to Review a Submittal: The Checklist

Everything above comes down to a handful of checks you run every time. Here’s the whole review as a checklist you can work through on each submittal. I keep something like this handy so nothing gets skipped when I’m moving fast.

The product and coordination checks use HVAC equipment as the example, since that’s my trade. The structure holds for any submittal, but the specific items you verify will be whatever your trade and your spec call for. Treat this as a model to adapt, not a universal list.

Orientation

• Read the submittal first. Identify what it is: cut sheet, shop drawings, certification, test report, or a full package.
• Pull the matching spec section and the relevant drawings (equipment schedule, plans).
• Confirm you’re working from the current drawing revision. Check for any addenda, CCDs, ASIs, or other changes released since the base set.

Completeness

• Check the spec’s submittal requirements and confirm every required item is in the package.
• Product data, performance data, dimensions, electrical data, certifications, and any required options.
• If anything’s missing, send it back to the vendor or contractor before going further.

Product Data vs. Spec

• Capacity: sensible and total cooling meet or exceed the schedule.
• Electrical: voltage and phase match the design.
• Cross-check breaker sizing and MOP against the electrical plans, not just the mechanical schedule.
• Physical fit: dimensions and weight match the design.
• Coil and configuration: rows, airflow, anything the schedule specified.
• Spec extras: coatings, filters, add options confirmed in the submitted unit.

Coordination

• Weight of the submitted unit matches the design weight (flag any increase for the structural engineer).
• Space and service clearances work in the actual location.
• Connections match what the other trades are roughing in: duct sizes, piping (CHW, drain, reheat), controls.
• Supports and isolation accounted for: concrete pad, spring isolators if required.

Decide and Route

• If it meets the plans and specs, prepare it to route up to the GC, CM, engineer, or architect.
• If the vendor sent the wrong thing, send it back for correction.
• If the product can’t meet the spec as written, start a variance or RFI.
• Log the submittal in your submittal log.
• Route it up with a cover sheet or transmittal, and record the date sent.

Download the Submittal Review Checklist (PDF)

Common Mistakes I’ve Seen

Rubber-stamping the vendor’s submittal. The vendor sends a package, it looks professional, and it’s easy to assume they got it right. They didn’t always. The vendor is selling equipment, not checking it against your project’s specs. That’s your job. Read it like it might be wrong, because sometimes it is.

Checking the submittal against the spec but not the drawings, or vice versa. The spec and the drawings each hold part of the requirements. The schedule gives you capacities and electrical. The spec gives you the options, coatings, and submittal requirements. Check only one and you’ll miss whatever lives in the other.

Approving against an outdated drawing set. If a revision came out and you’re reviewing against the old equipment schedule, you can approve something that was right last month and wrong today. Always confirm the revision before you sign off.

Forgetting the spec extras. This is the one that gets missed most. The unit hits every number in the schedule, so it looks good, but the spec called for a special coating or a specific filter that nobody confirmed. It looks like a clean approval right up until the equipment shows up without the option that was required.

Not documenting your review. If you spot a problem and mention it in a hallway conversation or a phone call, you have nothing to point to later. Put it in writing. The breaker story earlier is the whole reason why. Written proof is what decided who ate that cost.

Letting a submittal sit without following up. You route it up and assume the reviewer is on it. Weeks go by. Nobody’s looking at it, and now it’s your schedule taking the hit.

This cuts both ways. I’ve worked with GCs who would get the response back from the engineer and then just forget to return it to me. I’d have to follow up again and again to get that response in hand, because until I had it, I didn’t know my next steps.

And I’ll be honest, it goes the other way too. There have been times I forgot to send a submittal back to a sub after I got the response. It happens. That’s exactly why you track every submittal routing through you, in both directions. If it came to you, someone is waiting on you to move it along.

Frequently Asked Questions

How long does a submittal review take?

It depends on the project size and how many people are in the review chain. Small to medium projects often run on a two-week review window, while larger or more complex jobs can take a month or more. A fixed deadline like 14 days usually comes from the project’s own contract documents or spec section, not from the standard AIA A201 language, which only asks the architect to review submittals with “reasonable promptness.” Keep in mind that’s the design team’s review window, not yours. Your first-pass review as the contractor should be quick, ideally a day or two, so you’re not eating into that clock.

Who reviews submittals, the architect or the engineer?

Both, depending on what the submittal is for. The architect typically reviews architectural items, and the engineer reviews the systems in their discipline, so a mechanical submittal goes to the mechanical engineer, an electrical submittal to the electrical engineer, and so on. Before any of that, the submittal routes through the general contractor, who does the first-pass review covered in this article. The design team provides the final technical approval; the GC’s job is to make sure the package is complete and coordinated before it ever gets there.

What’s the difference between the contractor’s review and the designer’s review?

The contractor’s review, the one this article is about, checks that the package is complete and that the product matches the plans and specs, and confirms it coordinates with the other trades. It’s a completeness and coordination check. The designer’s review is a design review. The architect or engineer is confirming the submittal conforms to the design intent and the contract documents. Two different jobs. You’re making sure the right information is there and it all fits together. They’re making sure it matches what they designed.

What if the submittal requires a design change?

That’s outside what a submittal can do. A submittal proposes a product to satisfy the existing design. It can’t change the design itself. If the review turns up a situation where the design needs to change, whether the specified product doesn’t exist, can’t be furnished, or won’t work as drawn, that gets handled separately through an RFI or a variance request. Keep the submittal and the design change as two separate tracks. Trying to slip a design change through inside a submittal is how things get missed and approvals get muddy.

The Bottom Line

Knowing how to review a submittal as the contractor comes down to five things: get oriented, check completeness, verify the product against the spec, coordinate with the other trades and the current drawings, then log it and route it up. You’re not doing the engineer’s design review. You’re making sure the package is complete and correct before it ever gets to their desk, which is the cheapest place on the whole project to catch a problem.

Grab the checklist, keep it next to you on your next review, and build the habit of running every package through the same steps. The catches you make on your desk are the ones that don’t turn into the wrong unit sitting on a truck the week before a milestone.