On a building project, documents move between parties all day. The architect issues a drawing to the contractor. The contractor sends it on to a fabricator. The fabricator sends back a schedule. Months later, someone will need to know who had which version, and when.
A transmittal is how a project answers that.
What a transmittal is
A transmittal is the formal record of issuing documents from one party to another. It lists exactly which documents were sent and at which revision, who received them, and when. The recipient acknowledges receipt, and the acknowledgement becomes part of the record.
It is often confused with a submittal. In US construction, a submittal is a package sent for approval, such as a set of shop drawings. A transmittal is the record that something was sent at all.
Why document control turns on it
Document control has two jobs: making sure everyone works from the current revision, and being able to show who had what, and when.
The second job is the one that costs money when it fails. Audits, claims and disputes are rarely arguments about what happened. They are arguments about what was known, by whom, and on what date. They tend to be settled by whoever can reconstruct the record fastest.
A transmittal protects both sides. “We never received the revision” is a much weaker position than “we acknowledged it on the 14th”.
What a good transmittal holds
A transmittal is only as useful as the rules behind it.
- A number of its own. Drawn from a sequence for the project, and never reused, even when a transmittal turns out to be a mistake.
- The exact revision. It names the version issued. A later revision of the same drawing never rewrites what an earlier transmittal says was sent.
- An acknowledgement, with a due date. A transmittal past its date shows as overdue, rather than being forgotten.
- Both directions. Consultants and suppliers transmit their own deliverables back, and the record shows the party that issued them.
- Voiding, not deleting. A transmittal sent in error is voided with a stated reason. The number stays used and recipients see it marked void, so a copy already in someone’s hands is known to be dead.
Where ISO 19650 comes in
ISO 19650 is the international standard for information management on building projects. It describes a common data environment (CDE): the agreed single source of information for a project, where every document is collected, managed and issued.
The standard is about process, not product. In practice, a CDE has four jobs:
- Identity. Every document has one name, built from fields rather than typed by hand, so the same drawing can’t be filed under two names.
- State and suitability. What a document may be used for belongs to the document, not to the folder someone dragged it into.
- Succession. A new revision supersedes the old one. The old one stays readable, and stays marked as no longer current.
- Exchange. Issuing something to another party is a record: who, which revision, when, and whether they acknowledged it.
The transmittal is the fourth job. A CDE is only as good as its weakest one.
The record should come from the work
On most projects, the exchange record is an email with attachments and a spreadsheet register that someone updates afterwards, if they remember. Anything recorded by hand after the fact is a summary written by someone who already knows how things turned out. It keeps the conclusion and loses the evidence.
The better arrangement is that issuing the file creates the record. The revision goes to the recipient, the transmittal is raised in the same step, and the acknowledgement comes back onto the record without anyone chasing it. Nobody keeps the register. It keeps itself.
How ddx PMO does it
ddx PMO, our project management office (PMO) platform, files drawings and documents in a CDE inside the project record. Each document moves through four states: work in progress, shared, published and archived. Names are built from fields and checked on upload. Issuing a file raises a numbered transmittal, and suppliers acknowledge it in a portal of their own, which shows them only their own engagement.
Every file placed under control also joins the project’s wider record of risks, issues, decisions and actions. The drawing register and the answer to “why did this change?” sit in the same system.
It is not a modelling tool. It holds native CAD (computer-aided design) and BIM (building information modelling) files, names them, versions them and issues them, but it doesn’t open, combine or clash-check the models themselves. It sits beside the tools design teams already use.
We built it after running programme governance at the scale of One Bangkok, where the real record of what happened lived in email, chat and drawing revisions rather than in the tracker. And we’re our own first client: ddx PMO runs on ddx’s own live engagements first.
Read more about ddx PMO.
