Zepth Core · Document Management

Transmittals

It isn’t the document — it’s the proof the document was issued.

Last updated

Zepth Core module

Transmittals

AI agent built into the module
Issued from the registerPurpose-of-issue codesDistribution matrixAcknowledgment tracking

~25%

of drawings on job sites are out of date at any given moment

Industry estimates

Widely cited; primary sourcing is not firmly established, so we state it as an estimate.

$31.3B

a year of US rework caused by poor communication and poor project data

FMI research

~50%

of all rework traced to miscommunication and bad data together

FMI research

$60M+

the average US construction dispute — and over a year to resolve

Arcadis 2025

Overview

A transmittal is the formal cover record for issuing project information: which documents, which revisions, to whom, on what date, for what purpose. It is not the document — it is the proof the document was issued.

That distinction is pedantic right up until it is litigated. In a dispute about who received what and when, the transmittal log is the difference between evidence and assertion.

Why transmittals are critical

Consider the most common documentation dispute in construction. A revised structural drawing is issued. Weeks later, a subcontractor’s work is found built to the old revision. The subcontractor says: we never received Rev C.

If Rev C went out under a numbered transmittal, with a defined recipient list and an acknowledgment on record, the liability conversation is short. If it went out as an email attachment to whoever someone remembered to copy, the main contractor now owns an evidence-poor argument about an expensive piece of rework.

Every out-of-date sheet on a site is a transmittal that didn’t happen, wasn’t acknowledged, or didn’t recall what it superseded.

The role of transmittals in project performance

  • A transmittal is proof of issue; email is proof of sending. A transmittal adds what email lacks: a sequential number in a register, explicit revision and purpose-of-issue codes, a recipient list drawn from the project’s distribution matrix, and an acknowledgment loop. “It was in an email somewhere” and “Transmittal T-0457, Rev C, issued for construction, acknowledged 14 May” are different universes of evidence.

  • Purpose-of-issue codes govern use. For construction, for information, for approval. Building from a “for information” issue is a classic site failure, and the code on the transmittal is what makes the error attributable. The companion discipline is recall: superseded copies withdrawn or stamped, so the site holds one truth.

  • The distribution matrix decides who gets what — before anyone has to remember. A controlled table of document type against role: structural revisions reach the formwork subcontractor automatically; commercially sensitive documents don’t reach everyone. It is a living document, because firms change and people leave — and email-based distribution decays with every departure, since inboxes are personal silos and transmittal registers are project records.

  • Issue is not comprehension. A transmittal proves the drawing arrived. It does not prove the field understood what changed. Disciplined teams pair a major revision with a clouded markup or a revision note, so the crew knows what is different rather than merely that a new PDF exists.

What happens without transmittal discipline

Distribution runs on memory and email. The one recipient who mattered gets missed. Work proceeds on the superseded revision, and the cost is rework, delay to the following trades, and a liability fight with no clean record on either side.

Meanwhile, unacknowledged issues pile up unnoticed, and nobody can state what the current construction set was on a given date — which is the central question in defective-work disputes. At handover, the “issued” record turns out to be scattered across three years of inboxes belonging to people who no longer work there.

The average US dispute costs upwards of $60 million and takes over a year to resolve. A great many of them are, at root, arguments about who had which information when.

How Zepth runs transmittals

Transmittals are generated from the document register itself: current revisions only, recipients pulled from the project’s distribution rules, purpose codes enforced, acknowledgments tracked with read status visible. Superseded-revision alerts reach every registered holder automatically.

The transmittal log, the document register and the acknowledgment trail are one connected record. When the “who received Rev C” question arrives, the answer is a search, not an excavation.

The value

Why it matters

“We never received it” stops being an argument and becomes a lookup.

The superseded revision is retired from every holder, not just replaced in the system.

What the current construction set was on any given date has an answer — the central question in defective-work disputes.

The issued record survives the people who issued it, because it is a project record rather than a personal inbox.

Capabilities

What you can do

01

Issued from the register

Transmittals draw the live controlled revision from the document register — a stale copy cannot be issued by accident.

02

Purpose-of-issue codes

For construction, for information, for approval — recorded on the transmittal, so building from the wrong issue is attributable.

03

Distribution matrix

A controlled table of document type against role, so recipients are derived rather than remembered. It survives people leaving.

04

Acknowledgment tracking

Positive acknowledgment, not just “delivered” — with read status visible and overdue receipts chased from the register.

05

Automatic supersession alerts

When a revision is superseded, every registered holder of the old one is told.

06

Large-file support

Heavy BIM, CAD and Revit files issued without email size limits, with the formal issue-and-receipt trail intact.

The workflow

How it actually runs

  1. 1

    Prepare

    Documents selected, revisions confirmed current against the register, purpose-of-issue code set. The code is not optional — it is what governs use.

  2. 2

    Distribute

    Recipients pulled from the distribution matrix, not typed from memory. The delivery method is recorded with them.

  3. 3

    Acknowledge

    Recipients confirm receipt, and the acknowledgment timestamp is the legally interesting artifact. Unacknowledged transmittals get chased from the register rather than discovered in a dispute.

  4. 4

    Supersede

    Prior revisions flagged to every holder; site copies recalled or stamped. An issue that doesn’t retire what it replaces has done half a job.

  5. 5

    Register

    Every transmittal numbered and logged — the project’s answer to “what was current on any given date.”

AI that does the work

How AI changes Transmittals management.

Distribution completeness.

Issues are cross-checked against the distribution matrix and the gap is flagged — the structural revision that never reached the formwork subcontractor — before it becomes rework.

Unacknowledged-issue chasing.

Aging unacknowledged transmittals surface with owners and days outstanding, drafted into the weekly chase list rather than found during a dispute.

Change summaries.

When a major revision goes out, the what-changed note is drafted against the previous revision — closing the issue-versus-comprehension gap that transmittals alone cannot.

Dispute chronologies.

“Show every issue of drawing S-201, with recipients and acknowledgments” — the defective-work timeline assembled in seconds.

The engineer’s judgment stays in charge; the AI removes the latency and the blind spots.

Best practices

  • Issue every controlled document by transmittal, never by plain email. Email proves you sent something; only the transmittal proves what, to whom, at which revision, and for what purpose.
  • Require positive acknowledgment on anything consequential — IFC revisions, executed change orders. A “delivered” status is not receipt, and each unacknowledged transmittal is a future dispute in incubation.
  • Derive recipients from the distribution matrix, not from memory. Memory decays every time someone leaves the project, and it is always the one recipient who mattered who gets missed.
  • Pair a major revision with a note saying what changed. The transmittal proves the drawing arrived; it does not prove anyone understood it.

Dashboards & reporting

The transmittal register — numbered, dated, and searchable by document, revision, party and package — with outstanding-acknowledgment and distribution-gap views. Any document’s full issue history, with recipients and acknowledgment timestamps, assembles into a chronology on demand.

Live dashboards
Drill-down & filters
Export to Excel / PDF
FAQ

Common questions

What is a transmittal, and how is it different from emailing documents?

A transmittal is a numbered, logged, formal record of issue: documents, revisions, recipients, date, purpose. Email proves something was sent; a transmittal proves controlled issue and — with acknowledgment — receipt. Only one of them survives cross-examination well.

Read the full answer
Are transmittals legally significant?

Yes. In disputes over defective work, late information or building from superseded revisions, the transmittal log is core contemporaneous evidence of who held what information when.

Read the full answer
Who is liable if a subcontractor builds from a superseded drawing?

Broadly: whoever cannot prove their side of the issue. If the revised drawing was formally transmitted and acknowledged, the builder of the old revision owns the rework. If issue cannot be proven, the party responsible for distribution inherits the argument — and usually the cost.

Read the full answer
What should a transmittal include?

Transmittal number, date, sender and recipients, each document with its number, title and revision, the purpose-of-issue code, the method of delivery, and an acknowledgment requirement for critical issues.

What is a distribution matrix?

A controlled table defining which roles receive which document types automatically. It prevents both under-distribution — the subcontractor who never got the revision — and over-distribution, which means noise, and sensitive documents travelling further than they should.

Do recipients have to acknowledge transmittals?

For anything consequential — IFC revisions, executed change orders — best practice is positive acknowledgment, not just a “delivered” status. Unacknowledged transmittals should be chased as routine; each one is a future dispute in incubation.

What are purpose-of-issue codes?

They state what a document may be used for: issued for construction, for information, for approval. Building from a “for information” issue is a classic and expensive site failure, and the code on the transmittal is what makes the error attributable.

Read the full answer

Sources

  • FMI research — “Construction Disconnected” ($31.3B of US rework; communication and data as causes)
  • Industry estimates — outdated drawings on site (~25%; primary sourcing not firmly established)
  • Arcadis — Global Construction Disputes Report 2025 (dispute value and duration)

Zepth is the construction project delivery platform — it runs construction, procurement and asset management on one record, and does the work: reading the drawings, reviewing the submittals, matching the invoices and flagging the risks, with a human sign-off on anything consequential.

See it on your project.

A short, tailored walkthrough on your real workflow — no generic demo.