# What a Transmittal Has to Say

The fields a submittal transmittal must carry, why the reviewer files by them, the action line that decides what comes back, and one filled example.

Every package you send goes out under a transmittal, and most integrators treat it as a formality: a letterhead page with "please find enclosed" and a signature. Then the engineer's office logs the package under the wrong section, the returned markup can't be matched to the revision it answers, and eighteen months later nobody can prove what was sent on which day. 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.

That is why the transmittal, not the package, is what lawyers ask for first. It is also why Division 01 specifies its contents. The submittal procedures section of nearly every spec book includes a paragraph that reads something like "submittals shall be accompanied by a transmittal letter containing at least the following information," followed by a list. Find that paragraph in your spec before you design a template, because the list is contractual.

## The fields a reviewer files by

Across the Division 01 sections I have worked under, the list converges on the same core. One water utility spec on my desk demands, verbatim: date, project title and number, contractor's name and address, the number and revision of each drawing submitted, notification of deviations from the contract documents, submittal log number, and specification title and number. A published Division 01 from another owner asks for the same set and adds the paragraph reference within the section.

Group them by what the reader does with them:

**Identity.** Project name, the owner's project or contract number, and your own project number. Both numbers. The engineer files by theirs, you file by yours, and a transmittal carrying only one of them will be lost on somebody's desk. The industry's own best-practice standard for integrators makes this explicit: submittals and transmittals carry both the client's and the integrator's project reference.

**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](/learn/submittal-numbering-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.** A statement that the package either conforms to the contract documents or departs from them, and if it departs, exactly where. Nearly every spec makes this mandatory and adds teeth: the same water utility spec says that if the contractor fails to describe a variation, the contractor is not relieved of responsibility for executing the work per the contract even though the drawings were reviewed. A deviation you buried in a datasheet was never approved. A deviation you named on the transmittal, and the engineer stamped, is on the record.

**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, which starts the review clock. Not the date the PDF was compiled, not the date the drawings were finished.

## 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](/learn/answering-review-comments).

Add the date you need a response by, when the spec allows it. The engineer is not bound by your date, but a package that names a need date gets read before one that doesn't, and a written need date is the basis for a schedule claim if review drags.

## 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

A lift station panel package under a process control section, first issue, 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](/learn/control-system-submittal-package).

*Disclosure: I build [Submittal Kit](/), which generates the transmittal page from the project and the package so the numbers, section, and revision are never retyped, with a cover note field for the deviation statement. The [cover and transmittal templates](/help/cover-pages) and [numbering](/help/submittal-numbering) are yours to shape. The fields above are what the spec demands, whatever tool prints them.*

---
Submittal Kit · Field Guides · Updated 2026-09-06
Canonical: https://submittalkit.com/learn/what-a-transmittal-has-to-say