What a Transmittal Has to Say

Every package goes out under a transmittal, and most integrators treat it as a formality: letterhead, “please find enclosed,” signature. Then the engineer's office logs the package under the wrong section, or the returned markup loses its connection to the revision it answers. The transmittal exists to prevent exactly that, and it does so only if it carries the right fields.

This article is the field list, where each field comes from, and one filled example you can copy.

What a transmittal is for

A submittal is the content. The transmittal is the record of the exchange: who sent what, to whom, on what date, under what number, and what they expect back. The package can be replaced by Rev 2; the transmittal for Rev 1 stays true forever, because it describes an event rather than a document.

If the exchange becomes a question later, the transmittal is the first place you look. Many Division 01 sections specify its contents and routing. Find that paragraph in your project's submittal procedures section before you design the template. Its list, not a generic example, controls what your transmittal needs.

The fields a reviewer files by

Across the Division 01 sections I have worked under, the lists often converge on the same core: date, project identity, sender and recipient, submittal and specification references, enclosure details, requested action and any required deviation statement. Your section may add fields or route the package through another party.

Group them by what the reader does with them:

Identity. Project name, the owner's project or contract number, and your own project number when both are used. The engineer may file by theirs while you track by yours; carrying both reduces ambiguity.

Classification. The specification section number and title this package answers, and the submittal number in the format the spec dictates. The section is how the reviewer's log is organized; the number is how the rest of the conversation will refer to this package. Numbering conventions are their own topic: submittal numbering and revision schemes.

Contents. An itemized list of what is enclosed: each drawing by number and revision, each product data item by description, with copies or page counts where the spec still asks for them. "See attached" is not an itemized list. If the reviewer cannot check what arrived against what you said you sent, the transmittal has failed at its one job.

Deviations. When the project requires it, state whether the package departs from the contract documents and identify each departure precisely. Don't assume a difference buried in a datasheet was noticed or accepted. A clear statement lets the reviewer address it directly, but the project's approval and substitution procedures still govern.

Routing. Who it is from, who it is to, and how it went. The standard architect's transmittal form frames these as FROM, TO, and VIA. On a job where you are a subcontractor, the transmittal often goes to the general contractor, who re-transmits it to the engineer under their own number. Your transmittal should still name the engineer as the reviewer, so the package does not stall at the GC's desk as "information."

Date. The date it was sent, not the date the PDF was compiled or the drawings were finished. Use the project's procedure to determine when its review period starts.

The action requested

The most useful line on the form is the one most templates omit: what you want back. The architect's transmittal form calls it FOR and offers choices like approval, information, use as requested, comment, and distribution. Pick one, on purpose.

For review and approval is the normal case for shop drawings and product data. The package is an action submittal and you expect a stamp.

For information or for record means you are not asking for a stamp. Coordination drawings, test reports, and closeout material often go this way. Marking an action submittal "for information" is a quiet disaster: the engineer files it, nobody reviews it, and you proceed on nothing.

Resubmittal, with the prior submittal number and the review it answers. Most specs require a resubmittal to be marked as such and to carry a suffix on the original number. The transmittal for a resubmittal also has a second job, which is to say what changed; that discipline is covered in answering review comments on a resubmittal.

Add the date you need a response by, when the procedure allows it. The engineer is not bound by your date, but the date and its schedule reason put the need on the record. Any notice or schedule remedy still follows the project's contract terms.

The transmittal log

One row per transmittal, written the moment it goes out: number, date, section, contents summary, action requested, and to whom. Add the date it came back and the disposition when it does. This is the same log the submittal log keeps, seen from the exchange side rather than the package side, and on a small job they are the same spreadsheet.

The log answers the question that otherwise turns into an argument: did we send it, when, and what did they say. If you have ever tried to reconstruct that from sent mail, you know why the row is written at send time.

One filled example

This fictional example is a first-issue lift station panel package under a process control section, sent by a subcontractor to a GC:

TRANSMITTAL                                  No. 40 61 13-002
Date: 2026-03-09

Project:   Pine Creek WRF Lift Station Upgrades
Owner No.: 24-118              Our No.: PS26-014
To:        ABC Constructors (GC), attn. project manager
           for review by: XYZ Engineering, EOR
From:      Acme Controls, J. Smith, PM

Spec section: 40 61 13 Process Control System General Provisions
Submittal:    40 61 13-002, Rev 0 (initial)

Enclosed (1 PDF, 84 pages, bookmarked):
  1. Equipment schedule, LS-4 control panel (1 page)
  2. Panel drawings PS26-014-E01 through E07, Rev 0
  3. Product data, 23 catalog numbers, supplied part marked
  4. UL 508A listing certificate, panel shop file E123456

Deviations from contract documents: NONE.

Action requested: REVIEW AND APPROVAL.
Response needed by 2026-03-30 to hold panel fabrication start.

Every field a reviewer files by is present, both project numbers appear, the contents are itemized, the deviation statement is explicit, and the action line says what to do. The response-needed date is a request, not a demand, and the reason is stated so the schedule connection is on the record.

On the resubmittal, the number becomes 40 61 13-002 Rev 1 (or 002A, if the spec uses letters), the action line reads "RESUBMITTAL, answers review returned 2026-04-02," and the enclosure list marks what changed.

Building the template once

Read the Division 01 list, write the template to carry every field it names, and never fill one by hand that the project already knows. Project numbers, section, and submittal number are the same on every transmittal for that package; retyping them is where the typos come from, and a typo in the submittal number is the one that derails a review thread. What the package inside the transmittal should contain is the subject of what goes in a control system submittal package.

How Submittal Kit handles this

A typo in the submittal number is the one that derails a review thread, and retyping it on every transmittal is how it gets there. In Submittal Kit the Transmittal section builds itself at compile time: the submittal number in your name format, the revision label, and the primary spec section fill in from the project and the package. The Cover note field prints in the transmittal's NOTES block, which is where your deviation statement goes, and Draft note can start it from what the package records, including which review comments a resubmittal answers. Branch letterhead follows the project's office, so the Denver job never goes out wearing the Houston address. The cover designs are yours to shape. See submittal packages.

Disclosure: I build Submittal Kit. Check the fields above against your project's procedure, whatever tool prints them.