Submittal Cover Sheet: What to Include and How to Format It

A design reviewer opens a 70-page submittal package and lands on one page first: the submittal cover sheet. Before anyone reads a single product data sheet, that cover sheet sets the tone for the whole review. 

It signals whether the package was assembled with care or rushed to hit a deadline. A clear cover sheet lets the reviewer move through the rest of the project documents with confidence. A vague or half-finished one puts the submittal on the back foot before the technical review even starts.

What a submittal cover sheet actually is

A submittal cover sheet is the summary page that sits on top of a submittal package and tells the reviewer what they are looking at, who sent it, and what action is being requested. It is different from the transmittal, which is the routing slip that records who sent the package and when. 

The cover sheet goes further. It maps the submitted products and documents against the relevant spec sections so a GC, PM, or design team can orient in seconds. On a commercial project with dozens of products in a single submittal, that fast orientation is the difference between a short review and an hour of hunting through the documents.

What to include on a submittal cover sheet

A strong cover sheet carries a predictable set of information, organized so the reviewer never has to ask a question the sheet should have answered. Most teams create the cover sheet from a construction submittal review template and customize it for each project. 

Here is what belongs on the cover sheet.

Project and party identification

Start with the basics that route the document correctly: project name and number, the GC, the responsible subcontractor, and contact information for whoever prepared the submittal. Project administrators use this header to file the package against the right project and create the right record. Leave the information incomplete and those administrators have to chase down origin details before the review can begin.

Submittal number and spec section references

Every submittal cover sheet needs a unique submittal number and the spec sections it responds to. List the relevant sections, for example 23 74 13 for packaged rooftop units, so the reviewer can find the matching requirements without searching the full project manual. Those references are also what let the cover sheet reconcile cleanly against the submittal log later in the project.

Submittal type and action requested

State the submittal type (product data, samples, or shop drawings) and the action being requested: approval, review and comment, or for record. Telling the reviewer exactly what is needed keeps the package from stalling in a queue while someone decides what to do with it.

The compliance summary reviewers actually read

This is the part most templates leave blank, and it is the most valuable. A useful cover sheet summarizes how each one measures against the specs, and doesn’t just list products. The strongest versions show, per product, how many technical characteristics pass, how many fail, and how many are unknown and need clarification. 

Many teams download that summary from their review tool and drop the information onto the cover sheet. That summary is what turns a cover sheet from a filing label into a decision tool.

Skip the blank-page step. The BuildSync submittal cover sheet template has every field above, plus a Pass / Fail / Unknown summary that totals itself as you fill in each item. Free, no sign-up. Download the submittal cover sheet template.

How to format a submittal cover sheet for fast review

Formatting is about the reviewer's path through the page, not decoration. Order the cover sheet the way a reviewer thinks:

1. Identification at the top: project, parties, and prepared-by contacts.

2. The action requested, so the reviewer knows what is being asked of them.

3. The product-by-product compliance summary, the part they actually came for.

4. References to where the supporting documents live in the package.

Keep the cover sheet to one page where possible, and use a consistent layout across every submittal so reviewers know where to look each time.

The reviewer's perspective is the whole game. A GC buried under a hundred submittals will process the easy ones first. A cover sheet that clearly shows what was checked, and against which spec sections, is far easier to trust than a column of "comply, comply, comply" that may or may not reflect a real review. Doing the reviewer's work for them is one reliable way to move a package to the front of the line.

Tom Port, the co-founder of BuildSync, says:

What we tend to see is that a cover sheet tells a reviewer whether the contractor has done the work.

If it's clear and organized, and it shows how the products were checked against the specifications, the rest of the package starts with credibility.

A few formatting habits make the difference:

• Group products by spec section so related items stay together.

• Flag open items visibly instead of burying them in the list.

• Keep every reference traceable, so anyone can find the supporting page from the sheet.

Because a single package often mixes several types of construction submittals, the cover sheet has to make the type of each item obvious. If the team works from a shared cover sheet template, lock the structure and let people customize only the content.

Why the cover sheet matters for first-time approval

The cover sheet matters because it shapes the reviewer’s decision before they read the details, and first-time approval is where projects win or lose weeks. The industry average submittal rejection rate sits around 35%, and each rejection can add two or more weeks to the project timeline. 

A cover sheet that surfaces problems early, or proves the obvious ones were already caught, keeps a package from bouncing back over something avoidable. Teams that want to pass submittal review the first time treat the cover sheet as part of the review, not a label stapled on at the end.

Tom Port:

Construction runs on trust. When a cover sheet clearly shows what was checked, against which specifications, the design team approaches the package as a partner's work, not a problem to solve.

When your cover sheet is doing more work than your review

Here is the uncomfortable part. A polished submittal cover sheet on top of a rushed review is just nice packaging. If the compliance summary says "pass" but nobody actually checked the light transmittance value or the refrigerant type against the spec, the cover sheet is making a promise the review cannot keep. That gap is what reaches the design team and comes back as a rejection weeks later.

This is where deep technical analysis changes the math. Teams upload the submittal with the project plans and specs, and BuildSync reviews every characteristic against them, assigning each one a status:

• Pass: the characteristic meets the spec.

• Fail: it does not, and needs a fix before resubmission.

• Unknown: the information is ambiguous or missing, so a human makes the call.

Each status links to its reason and source documents, one click away. Users download the compliance overview, which becomes the honest backbone of the cover sheet and saves teams 70 to 80% of the time otherwise spent on manual submittal review.

On one project, Monteith Construction used it to review a single 530-page submittal against multiple spec sections. Project Engineer Jacob Delargy made BuildSync the first stop for every submittal, then used the generated report and markup to navigate the package before it reached the architect and engineer. He credits it with surfacing specs he would not have thought to reference on his own, which is exactly the kind of catch that keeps a cover sheet honest.

Tom Port says:

Anyone can write 'comply' down a column. A real compliance check shows what was reviewed, what passed, what failed, and what still needs clarification. That difference matters because the design team isn't looking for conclusions, they're looking for evidence they can trust.