Project Documents & Submittals

Document Transmittal Template for Material Submittals and Approval Records

Construction projects generate a large volume of documents: shop drawings, technical data sheets, test reports, product certificates, material submittals, approvals, and revised documents.

Email can send those files, but email alone does not always provide a clear document-control record.

A document transmittal creates a formal record showing:

• what was sent;
• which revision was sent;
• who sent it;
• who received it;
• why it was issued;
• what response was required;
• what happened after issue.

For procurement and project teams, this becomes especially important when material approval affects purchasing, production, or delivery.

A useful document transmittal should allow someone months later to answer:

Exactly what project information was formally issued, when was it sent, and what action followed?

---

When Should You Use a Document Transmittal?

Not every project email needs a transmittal.

A formal transmittal is most useful when the document revision, issue date, or approval history may matter later.

Typical examples include:

• material submittals;
• shop drawings;
• technical data sheets;
• test reports;
• product certificates;
• samples and sample records;
• revised drawings;
• consultant comments;
• approved documents;
• supplier technical documents;
• handover records.

For a simple informal question, normal email may be sufficient.

But when a document could affect:

• approval;
• procurement release;
• production;
• installation;
• contractual responsibility;

it is better to create a traceable issue record.

---

What Should One Transmittal Represent?

A practical rule is:

One transmittal = one formal document issue.

That issue may contain:

• one document;
• several related documents;
• one complete material submittal package;
• one revised package.

You do not necessarily need a separate transmittal for every attachment.

For example:

TRN-025

Shower Enclosure Material Submittal

Documents included:

• Technical Data Sheet Rev.02
• Shop Drawing Rev.03
• Glass Test Report Rev.00
• Finish Sample Record

These documents belong to the same formal submission and can be issued under one transmittal.

---

Step 1: Create a Unique Transmittal Number

Every transmittal should have a unique reference number.

A simple system may use:

TRN-001

TRN-002

TRN-003

Larger projects may include project or discipline codes, for example:

HOTEL-ARCH-TRN-024

or:

PRJ01-MEP-TRN-018

The exact format matters less than consistency.

A good numbering system should be:

• unique;
• sequential;
• searchable;
• easy to understand;
• used consistently throughout the project.

Avoid file-control references such as:

• Final
• Final 2
• New
• Latest
• Updated Final

These labels do not create a reliable audit trail.

---

Step 2: Record the Basic Transmittal Information

The transmittal header should identify the issue clearly.

Useful fields include:

• Transmittal Number
• Project Name
• Project Number
• Date
• From
• To
• Sender Company
• Recipient Company
• Contact Person
• Email
• Subject
• Procurement Package
• Purpose of Issue

Depending on the project, you may also record:

• contract package;
• discipline;
• supplier;
• submittal number;
• RFQ number;
• purchase order number.

The objective is simple:

Someone reading the transmittal later should understand the context without searching through the original email thread.

---

Step 3: List Every Document Being Sent

This is the most important part of the transmittal.

Where the package includes certificates or regulatory evidence, use the Construction Product Certification Guide to confirm that the document actually supports the material being submitted.

Each document should normally have its own line.

Useful fields include:

• Document Number
• Document Title
• Revision
• Document Date
• File Name
• Document Type
• Number of Files or Copies
• Remarks

For example:

The revision field is critical.

A title such as:

Shower Enclosure Shop Drawing

does not tell you whether Rev.01, Rev.02, or Rev.03 was actually issued.

The transmittal should identify the exact revision that was sent.

---

Step 4: Use Standard Purpose and Action Codes

A recipient should know why the documents were issued.

Avoid inconsistent free-text wording where possible.

Common purpose codes include:

For Approval

The recipient is expected to approve, reject, or return comments.

For Review

The recipient should review and comment.

For Information

The document is being issued for awareness. Formal approval is not required.

For Record

The document is being issued to maintain the formal project record.

For Construction

Approved information is being released for use in execution.

For Coordination

The document is being issued to support coordination with another discipline or party.

Other project-specific codes may include:

• As Requested
• For Tender
• Revise and Resubmit

Use only the codes your team actually needs.

Too many status options can make document control harder rather than better.

---

Step 5: Define the Required Response

If the recipient needs to do something, record it clearly.

Useful fields include:

• Action Required
• Response Required?
• Response Due Date
• Responsible Reviewer

Possible actions include:

• Approve
• Review and Comment
• Confirm Receipt
• Return Signed Copy
• Revise
• No Action Required

For example:

Purpose: For Approval Required Action: Review and approve material submittal Response Due: August 27

This is much clearer than simply sending documents with:

“Please review.”

A useful rule is:

If a response is required, define both the action and the due date.

---

Step 6: Check Document Revisions Before Sending

Before the transmittal is issued, compare the listed documents against the actual attachments or uploaded files.

Check:

• latest revision;
• document number;
• title;
• file name;
• title block;
• submittal log;
• all required attachments.

Remove superseded documents from the issue package.

A common document-control error is:

Transmittal lists Rev.03

but:

Attached drawing is Rev.02

The email may have been delivered correctly, but the formal record is now wrong.

For critical project documents, this can create confusion later about which version was reviewed or approved.

---

Step 7: Record the Actual Issue Date

The transmittal should show when the documents were formally issued.

Issue and approval dates can also affect package timing in the Construction Procurement Schedule when procurement or production cannot proceed until formal approval is received.

Where relevant, distinguish between:

• Prepared Date
• Issued Date

The issue date can later affect:

• consultant review period;
• approval deadline;
• procurement release;
• production start;
• contractual delay analysis.

Do not rely only on the file creation date.

The important date is when the project information was actually transmitted to the other party.

---

Step 8: Record Receipt or Acknowledgement

Sending a document does not always prove that the intended recipient received it.

Depending on project importance, retain evidence such as:

• sent email record;
• recipient acknowledgement;
• document-management platform receipt;
• signed transmittal;
• system upload confirmation.

Useful fields include:

• Sent Date
• Received Date
• Received By
• Acknowledged Date
• Receipt Reference

For routine documents, a formal signed acknowledgement may not be necessary.

For critical approval records, however:

Sent is not always the same as confirmed received.

---

Document Transmittal Template

A simple document transmittal can use three sections.

Transmittal Header

Document List

Receipt / Response

Add fields such as:

• Sent By
• Sent Date
• Received By
• Acknowledged Date
• Review Result
• Returned Reference

This can be created in:

• Excel;
• Word;
• Google Sheets;
• a construction document-control platform.

The tool matters less than maintaining a consistent record.

---

Link the Transmittal to the Material Submittal

For construction procurement, a transmittal often belongs to a larger material approval process.

The transmittal sits inside the wider Construction Material Submittal Process and should remain tied to the specific Material Approval Request (MAR) or technical package being reviewed.

Record the related:

• Submittal Number
• Material Package
• Supplier
• Current Revision
• Previous Transmittal

For example:

Submittal: MS-018 Transmittal: TRN-025 Package: Shower Enclosures Supplier: Supplier A

This creates a traceable chain:

Material Submittal

↓

Transmittal

↓

Issued Documents

↓

Consultant Review

↓

Approval Result

If a question appears later, the team can identify which exact documents supported the approval.

---

How to Handle Revised Documents

When a document is revised and reissued, do not edit the old transmittal to show the new revision.

Create a new transmittal.

For example:

TRN-025

Shop Drawing Rev.02 issued for approval.

Consultant returns comments.

Supplier revises the drawing.

TRN-031

Shop Drawing Rev.03 issued for approval.

Now the project has a clear record showing:

• what was sent first;
• what changed;
• when the revision was issued.

Useful fields for revised issues include:

• Previous Revision
• New Revision
• Reason for Revision
• Previous Transmittal Reference

The principle is:

Historical issue records should remain historical.

Do not overwrite them with later information.

---

Connect the Transmittal to Approval Status

For procurement teams, the process should not stop after the transmittal is sent.

After issue, update the Construction Submittal Log so the project-wide status remains synchronized with the detailed transmittal record.

The review outcome can directly affect purchasing or production.

Possible statuses include:

• Submitted
• Under Review
• Approved
• Approved with Comments
• Revise and Resubmit
• Rejected
• Superseded

If Approved

Update submittal log → Release procurement or production where applicable

If Approved With Comments

Check whether the comments affect:

• dimensions;
• materials;
• finish;
• production;
• cost.

If Revise and Resubmit

Supplier revises documents → New revision → New transmittal

If Rejected

Hold procurement action → Resolve technical issue

This is why the transmittal is not only an administrative cover sheet.

It sits inside a real procurement decision process.

---

Document Transmittal vs Submittal Log

These two tools serve different purposes.

For example, a project may have:

150 material and technical submittals

inside one overall submittal log.

One individual submittal may then generate several transmittals:

• original submission;
• revised submission;
• final approved issue.

So:

The submittal log gives the project-wide status. The transmittal gives the detailed record of each formal document issue.

---

Document Transmittal vs Email

Email and transmittals also serve different purposes.

Email

Good for:

• communication;
• discussion;
• questions;
• sending files.

Transmittal

Good for:

• formal document issue;
• revision control;
• traceability;
• required action;
• project record.

An email may say:

“Please see attached revised shop drawings.”

A transmittal says:

• Shop Drawing SD-001
• Revision 03
• Issued August 20
• For Approval
• Response Required August 27

For critical project documents, the transmittal should remain the controlled reference even if email is the actual delivery method.

---

Common Document Transmittal Mistakes

Missing Revision Numbers

Without the revision, it may be impossible to prove which document version was issued.

---

Sending Files Not Listed on the Transmittal

The formal record no longer matches the actual issue.

---

Listing Documents That Were Not Sent

This creates the same problem in reverse.

Always compare the transmittal against the attachments before issue.

---

No Purpose or Action

The recipient may not know whether the document requires approval, review, or no action.

---

No Response Due Date

Approval delays become harder to manage.

---

Reusing a Transmittal Number

Every new formal issue should normally have a unique transmittal number.

---

Overwriting Old Transmittals

Do not change historical issue records when revised documents are sent.

---

Failing to Update the Submittal Log

The detailed issue record and project-level approval tracking should remain connected.

---

Document Transmittal Checklist

Before issuing a formal transmittal, confirm:

• Unique transmittal number assigned
• Project identified
• Sender identified
• Recipient identified
• Issue date recorded
• Subject or package recorded
• Related submittal number recorded
• Every document listed
• Document numbers checked
• Revisions checked
• Actual attachments verified
• Purpose code assigned
• Required action defined
• Response due date recorded
• Sent record retained
• Receipt acknowledgement retained where required
• Review result linked
• Submittal log updated
• Revised issue uses a new transmittal number

---

Tools and Resources for Document Transmittals

Project and procurement teams may use:

• document transmittal templates;
• submittal logs;
• document-control spreadsheets;
• approval trackers;
• material submittal templates;
• construction document-management platforms;
• RFI and submittal management tools.

The most useful tool depends on the size and complexity of the project.

A small team may manage transmittals effectively in Excel or Word.

A larger project may need a centralized document-control platform with automated revision history and receipt records.

Build Procurement Hub organizes transmittal, submittal, approval, and project-document resources around actual procurement and construction workflows so teams can find the right tool for each task.

---

What Comes After the Transmittal Is Sent?

The next action depends on the purpose of issue.

For Approval

Transmittal → Consultant Review → Approval Result

Approved

Update Submittal Log → Procurement / Production Continues

Revise and Resubmit

Supplier Revises → New Revision → New Transmittal

Rejected

Hold Procurement → Resolve Technical Issue

The complete workflow becomes:

Prepare Documents

↓

Create Transmittal

↓

Issue Documents

↓

Record Receipt

↓

Review / Approval

↓

Update Submittal Log

↓

Release Procurement Action or Resubmit

The key principle is simple:

A document transmittal is not just a cover sheet. It is the audit record showing exactly what project information was formally issued, which revision was sent, when it was sent, and what happened next.

---

Keep Every Formal Document Issue Traceable

Use Project Documents & Submittals resources to manage transmittals, material submittals, approval logs and revision history. Keep the detailed issue record connected to the project-wide submittal status and the procurement action that follows approval.

Explore Project Documents & Submittals Check Product Certification Resources

FAQ

What is a document transmittal in construction?

A document transmittal is a formal record identifying which project documents were issued, their revision numbers, sender, recipient, issue date, purpose, and required response.

What should a document transmittal template include?

It should normally include a transmittal number, project information, sender and recipient, issue date, subject, document list, revision numbers, purpose, required action, response due date, and receipt or response information.

What is the difference between a transmittal and a submittal?

A submittal is the technical content being submitted for review or approval. A transmittal is the formal record used to issue that content to another project party.

Should revised documents use a new transmittal number?

Yes. A revised formal issue should normally receive a new transmittal number so the project maintains a clear history of what was issued at each stage.