Construction document control is the discipline of tracking every project document — drawings, specifications, submittals, transmittals, and correspondence — through a single numbered register so that everyone works from the current revision and every exchange is recorded. Done well, it prevents rework caused by superseded drawings, and it produces the contemporaneous record you need to defend a delay or variation claim. Four things sit at its core: a register with disciplined numbering and revision status, transmittals that prove what was issued and when, RFI and correspondence logs, and an audit trail no one can quietly edit.
What is construction document control?
Document control is the system and process for creating, reviewing, distributing, storing, and tracking controlled documents on a project. A controlled document is any document whose version matters — if the wrong revision reaches the field, someone builds the wrong thing. That covers drawings, specs, method statements, submittals, RFIs, and formal correspondence, but usually not casual internal notes.
The goal is deceptively simple: make sure the right people always have the right version, and be able to prove, months or years later, exactly who received what and when. On a small job you can almost do this by hand. On anything with multiple disciplines, a design team, subcontractors, and a client, the bookkeeping compounds until it becomes its own workstream — which is why dedicated document controllers exist.
Note that document control is not the same as document management. A shared drive manages files (stores and organizes them). Document control adds process: numbering rules, revision governance, review routing, distribution records, and an audit trail.
The document register: numbering, revisions, and status
The register is the master index of every controlled document. It is the single source of truth for "what is the current revision of drawing X, and where is it in its lifecycle?" Everything else in document control hangs off the register.
Document numbering
A good document number is a stable, unique identifier that encodes just enough metadata to sort and find documents without opening them. A typical structured number looks like:
PRJ-CIV-DWG-0042
where the segments mean project, discipline (civil), type (drawing), and a sequential number. Standards such as ISO 19650 formalize this, but the principle is universal: agree the numbering convention up front, publish it, and never reuse or reissue a number for a different document. The number identifies the document for its whole life; the revision identifies the version.
Revisions and status
Every time a document changes materially, it gets a new revision. Preliminary or work-in-progress issues often use a prelim sequence (P01, P02) or letters (Rev A, B, C); construction issues switch to a numeric sequence (C01, C02). The register keeps the full revision history so you can answer "what changed between Rev C and Rev D, and who approved it?"
Alongside the revision sits a status (or suitability) code describing what the document may be used for. ISO 19650 uses codes such as S0–S4 for work-in-progress and shared information and A-codes for authorized/approved output. The status matters as much as the revision: a drawing at "shared for coordination" is not a drawing "approved for construction," and building from the former is a classic, avoidable dispute.
A register that captures number, revision, status, issue date, and current holder is doing most of the job. The trouble starts when that register lives in a spreadsheet that only one person updates.
What is a transmittal and why does it matter?
A transmittal is a formal cover record that accompanies documents issued from one party to another. It lists the documents and revisions being sent, the issue purpose (for review, for construction, for information), the recipients, and the date. The documents are the payload; the transmittal is the proof of delivery.
Transmittals matter for one reason above all others: they establish the contemporaneous record of what was issued, to whom, when, and for what purpose. That record is the backbone of claims defense. If a subcontractor argues they never received the revised foundation drawing, the transmittal — with its date and recipient list — settles it. If the client claims a design was issued late, the transmittal log shows the actual issue date against the contractual deadline.
Because transmittals are evidence, they need to be numbered, logged, and stored with the same rigor as the register itself. A transmittal that lives only in someone's sent-mail folder is worth far less than one in a shared, searchable log with delivery confirmation.
RFIs and correspondence tracking
An RFI (Request for Information) is a formal query raised when drawings or specifications are unclear, conflicting, or incomplete. RFIs are unavoidable on real projects, and how you track them separates smooth jobs from disputed ones.
A well-run RFI log captures, at minimum:
| Field | Why it matters |
|---|---|
| RFI number and date raised | Establishes the timeline |
| Discipline / area | Routes it to the right reviewer |
| Question and supporting references | Frames the issue clearly |
| Response required by | Drives turnaround and flags overdue items |
| Response and date answered | Closes the loop |
| Cost / time impact flag | Links the RFI to potential variations or delay |
| Status (open / answered / closed) | Shows what is outstanding |
The concept that ties an RFI log together is ball-in-court: at any moment, one party owns the next action. Good tracking makes ball-in-court visible so nothing stalls silently. An RFI that sits unanswered past its due date is not just an annoyance — if it delayed the works, it may become the anchor of a delay claim, and the log is your evidence of when the ball landed and how long it stayed there.
The same discipline extends to general correspondence: formal letters, notices, and instructions all benefit from being numbered, threaded, and searchable rather than scattered across inboxes.
Review routing and approval chains
Most controlled documents pass through a review cycle before they are authorized. Review routing is the process of getting a document to the right reviewers, consolidating their comments, and recording a decision.
The pieces that make review routing work:
- A distribution matrix — who reviews what, by discipline and document type, so routing is a rule rather than a daily judgment call.
- Consolidated markups — comments from multiple reviewers merged into one coordinated response, rather than conflicting redlines returned separately.
- An approval status — many projects use a simple three-code scheme: approved (often "Code 1" or Status A), approved with comments (Code 2 / Status B), and rejected or revise-and-resubmit (Code 3 / Status C). The code determines whether the document can be issued or has to come back around.
- Turnaround SLAs — an agreed number of working days for a review. Without a clock, reviews expand to fill all available time, and the review backlog quietly becomes the critical path.
When routing is manual, the failure mode is predictable: documents wait in inboxes, reviews miss their SLA, and no one can see the queue. Automating the routing and putting a visible clock on each review is where a dedicated tool earns its keep. Kazinex Workflows handles this with review routing that enforces SLAs and shows exactly which items are approaching or past their due date.
Audit trails and claims defense
An audit trail is the immutable, time-stamped record of every action taken on a document: who created it, who revised it, who issued it, who received it, who reviewed it, and when. The word that matters is immutable — an audit trail you can edit after the fact is not evidence.
This is where document control quietly pays for itself. Construction disputes are won and lost on contemporaneous records — records created at the time, in the normal course of business, not reconstructed for a claim. A complete audit trail lets you demonstrate that a notice was served within the contractual window, that a drawing was issued on a specific date, or that an RFI response was late. Reconstructing that story from email six months after practical completion is painful, incomplete, and unpersuasive; producing it from a controlled system is a click.
Signs your project has outgrown email and spreadsheets
Email plus a spreadsheet register is a legitimate starting point. Here are the signals that it has become a liability rather than a system:
- Version confusion in the field. Someone builds from a superseded drawing because they were never sure which revision was current.
- The register is always slightly wrong. It depends on one person updating a spreadsheet, and it lags reality.
- Transmittals live in sent-mail. You cannot produce a clean, searchable log of what was issued to whom.
- RFIs slip past their due dates unnoticed. There is no visible ball-in-court and no overdue alert.
- No proof of delivery. A recipient claims they never received a document and you cannot prove otherwise.
- Reviews stall invisibly. Nobody can see the review queue or how long items have been waiting.
- Close-out is a scramble. Assembling the audit trail at the end of the project takes weeks because the record is scattered.
If several of these are familiar, the project has outgrown ad-hoc tooling. Purpose-built document control platforms consolidate the register, transmittals, RFIs, correspondence, review routing, and audit trail into one system. Kazinex Workflows is a modern alternative to legacy tools like Aconex, built to keep the register, transmittals, RFI and correspondence logs, and SLA-driven review routing in a single audited place — so the contemporaneous record assembles itself as you work rather than being reconstructed at close-out.
Frequently asked questions
What is the difference between a transmittal and a submittal? A submittal is the document being sent for review or approval (a shop drawing, a material sample data sheet); a transmittal is the cover record that formally issues it and proves what was sent, to whom, and when.
How long should construction document records be kept? Retention is usually driven by the contract and the applicable limitation period for claims in your jurisdiction, which commonly runs several years past completion — so most projects retain the full controlled record and audit trail for the life of any potential liability.
What does "ball-in-court" mean in RFI tracking? Ball-in-court identifies which party owns the next action on an open item at any given moment, so an RFI or review never stalls silently with an unclear owner.
Is document control the same as document management? No — document management stores and organizes files, while document control adds the governing process: numbering rules, revision and status control, review routing, distribution records, and an immutable audit trail.