Construction document management software holds drawings and their revisions, who has been issued what, the submittal and approval cycle for drawings the contractor produces, contracts and correspondence, statutory permissions, and the as-built record. With Pentoggle, a contractor can describe its drawing numbering, issue process and approval chains and generate the starting application around them.
The problem this addresses is narrow and expensive. Drawings change throughout a project, several parties hold copies, and work gets built from whichever version happens to be in front of the person doing it. Everything else in document management is filing. This part is money.
Many contractors already hold drawings in AutoCAD or Revit and share them by email or a shared drive. Those hold the file. What they do not hold is which revision each site and each subcontractor is actually working from.
Key takeaways
- The revision that matters is the one physically in use at site, which is frequently not the current one.
- Issuing a drawing and having it received are different events, and receipt is what confirms that the revision has reached the intended recipient.
- Rework from a superseded drawing is usually discovered too late to attribute, so it gets absorbed as a general cost.
- Where a late revision caused the rework, the receipt date is what turns a complaint into a case.
- A useful number is the count of drawings where the revision in use at site is not the current revision.
What the drawing register and the shared folder do well, and where they stop
Many contractors run a drawing register, keep the current set in a shared folder, and issue by email. A competent document controller keeps this in good order, and on a small project it works.
The limits are about the last mile and about proof.
The folder is not the site.
Site works from prints. Prints are made on a day, pinned up, and stay there. A revision issued to the folder does not walk to the board and take the old sheet down.
Issue is recorded, receipt is not.
An email with an attachment records that something was sent. Whether the site engineer opened it, whether the subcontractor's supervisor saw it, and whether the print in use was replaced are all unknown.
Superseded copies keep working.
Old prints exist in vehicles, in subcontractors' offices, and folded in somebody's bag. Nothing removes them.
As-builts are reconstructed.
Deviations are agreed during construction and noted informally, then compiled into as-built drawings at the end by someone reconstructing months of decisions from memory and correspondence.
What document management software holds
The drawing register
Each drawing with its number, title, discipline, current revision, date and status.
Revision history
What changed at each revision and why, so a superseded drawing can be understood rather than merely replaced.
Transmittals with acknowledgement
What was issued to whom, when, and confirmation that it was received.
Revision in use at site
Which revision each site, area and subcontractor is currently working from, held separately from what was issued.
The submittal cycle
Shop drawings and documents submitted for approval, with comments, resubmissions and current status.
Contracts and correspondence
Agreements, work orders, letters and notices, held against the project and findable by subject.
Statutory permissions
Approvals and permissions with validity, held where they can be produced.
As-built capture
Deviations from drawing recorded when they are agreed rather than reconstructed at the end.
The only revision that matters is the one on the wall
This is the whole argument for building anything here.
A drawing is revised because something needed to change. It is issued properly, through the correct channel, to the correct people. The document control record shows revision D issued on the fourteenth, and by that record everything has been done.
At site, a print of revision B is on the board in the site office. It has been there for six weeks. The site engineer received the email about revision D, was on site when it arrived, intended to print it, and did not. The bar bending gang works from what is on the board.
The steel goes in to revision B. It is discovered at the pre-pour check if somebody is thorough, and after the pour if not. Either way the cost is real, and by the time anybody investigates, the question of who was responsible is genuinely unclear, because everyone did approximately their job.
The gap is between issue and use, and closing it requires tracking use rather than issue. Which revision is each site currently building from, confirmed by the person building from it. That is a different record from the transmittal, and many contractors do not keep it.
It is also cheap. A site engineer confirming on a phone that they are now working from revision D, per drawing, takes seconds. What it produces is a list of drawings where the site's revision and the current revision differ, which is the list somebody should look at every week and which currently exists nowhere.
A drawing issued is not a drawing received
Transmittals exist because construction learned this a long time ago, and email has quietly eroded it.
A formal transmittal records what was issued, to whom, on what date, and is acknowledged. An email records that a message was sent. The difference matters in two directions.
Operationally, an unacknowledged issue is an assumption. The document controller believes the subcontractor has revision D. The subcontractor's supervisor may not have opened the attachment. Nothing in the process detects this until something is built wrong.
Commercially, receipt dates can become important in disputes. Where a revision arrived late and caused rework or delay, the case may depend on when it was received rather than when it was sent, and on the work having been in progress at that point. A contractor who can produce acknowledged receipt dates is in a position to make that case. One relying on an email thread usually is not. Whether any entitlement follows is a contract question for your contracts team.
Acknowledgement does not need to be heavy. Confirmation from the recipient, timestamped, against the specific drawing and revision, is sufficient and takes a moment. The value is that it converts an assumption into a fact.
Rework from an old drawing has no owner
When work is built to a superseded revision, the cost is real and the responsibility is diffuse.
The design team issued correctly. Document control transmitted correctly. The site engineer received it and was busy. The subcontractor built what was in front of them. The checker did not catch it because a pre-pour check verifies the work against the drawing at hand, and the drawing at hand was the old one.
Because no single party clearly failed, the cost gets absorbed rather than attributed. It appears as rework if that is being recorded at all, and as ordinary production if it is not, which is the usual case.
The result is that a recurring and expensive failure may not accumulate into usable evidence, making it harder to identify and fix. A contractor who can say how many instances occurred last year, and what they cost, has a much stronger basis for deciding where revision control needs attention.
Recording it requires only that rework entries carry a cause, with superseded drawing as one of the options. That single field turns an anecdote into a figure, and the figure is usually large enough to justify everything else on this page.
As-builts are compiled from memory, and they should not be
At handover, most contracts require drawings showing what was actually built. Where a deviation from the design was agreed and executed, the as-built should reflect it.
What generally happens is that deviations are agreed during construction, verbally or in correspondence, executed, and remembered by whoever was involved. At the end of the project somebody sits down to produce as-builts and reconstructs them from marked-up prints of varying reliability, correspondence, and the recollection of people who may have left.
The consequence is that as-builts can be incomplete or inaccurate, which matters most for concealed services. An owner drilling into a wall five years later relies on a drawing that shows a conduit route somebody reconstructed from memory.
The alternative is to capture the deviation when it is agreed. What changed, where, why, who approved it, with a photograph before concealment. That entry takes a minute at the time and can be difficult to reproduce accurately later. Assembled through the project, the as-built exercise becomes a drafting task rather than an investigation.
For contractors whose handover payment depends on the documentation package, which the industrial construction guide describes, this is not a quality nicety. It is the difference between being paid on time and chasing records for a quarter.
Where document management looks different by business type
- Facade Contractor Software, where drawing revisions map onto specific panel types already in fabrication.
- Industrial Construction Software, where vendor drawings arrive late and drive foundation work built to fine tolerances.
- MEP Contractor Software, where coordination drawings change frequently and much of the work is concealed.
- General Contractor Software, where drawings have to reach several subcontractors and each holds their own copies.
- Interior Fit-Out Contractor Software, where changes are frequent and the programme is too short to absorb a revision error.
Why contractors choose Pentoggle for document management
Revision in use, not just revision issued
What each site and subcontractor is actually building from, confirmed by them.
Transmittals that are acknowledged
Issue and receipt as separate facts, with dates that stand up later.
Submittals tracked as waiting items
Shop drawings with comments, resubmissions and how long each has been out.
As-builts captured as you go
Deviations recorded when agreed, with photographs before concealment.
Sits around your accounting tools
Drawings stay where your designers work. This holds status, issue and use.
A useful number for document management
The count of drawings where the revision in use at site differs from the current revision.
It measures the actual risk rather than the process. A document control function can be operating perfectly and this number can still be high, which is precisely the point, because the failure happens after issue.
Review it weekly and resolve the list. It is short in a well run project and the items on it are specific: one drawing, one location, one person to confirm with. That is a fifteen minute task that prevents a category of rework nobody can attribute afterwards.
Watch which drawings recur. A drawing that is repeatedly out of date at site usually means either the revision rate is too high for the site to absorb, which is a design coordination problem, or the drawing goes to somebody whose process for replacing prints does not work, which is fixable directly.
The number needs site confirmation of the revision in use, which is the one new habit this requires. It takes seconds per drawing and it is often the only part of document control that touches what actually gets built.
Ready to build document management software?
Everyone can tell you what the current drawing is. Very few can tell you what is being built from.