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.
It isn’t the document — it’s the proof the document was issued.
Last updated
Zepth Core module
~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
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.
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.
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.
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.
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.
“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.
Transmittals draw the live controlled revision from the document register — a stale copy cannot be issued by accident.
For construction, for information, for approval — recorded on the transmittal, so building from the wrong issue is attributable.
A controlled table of document type against role, so recipients are derived rather than remembered. It survives people leaving.
Positive acknowledgment, not just “delivered” — with read status visible and overdue receipts chased from the register.
When a revision is superseded, every registered holder of the old one is told.
Heavy BIM, CAD and Revit files issued without email size limits, with the formal issue-and-receipt trail intact.
Documents selected, revisions confirmed current against the register, purpose-of-issue code set. The code is not optional — it is what governs use.
Recipients pulled from the distribution matrix, not typed from memory. The delivery method is recorded with them.
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.
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.
Every transmittal numbered and logged — the project’s answer to “what was current on any given date.”
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.
Aging unacknowledged transmittals surface with owners and days outstanding, drafted into the weekly chase list rather than found during a dispute.
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.
“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.
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.
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 answerYes. 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 answerBroadly: 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 answerTransmittal 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.
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.
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.
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 answerRelated modules
Related answers
Terms defined here
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.
A short, tailored walkthrough on your real workflow — no generic demo.