Construction Rework: Where It Starts and How to Stop It

Construction rework is one of those problems that every team knows is expensive and almost no one tracks precisely enough to address at the root. You see it in change orders. You see it in schedule slippage. You see it when a crew gets pulled off one task to tear out work that passed inspection last week. What you rarely see is a clear line back to where the mistake actually entered the project.

The numbers are striking. A joint study by Autodesk and FMI found that rework accounts for roughly 5% of total U.S. construction spending, a figure that translates to more than $65 billion in annual losses. That sum does not capture the full cost. It excludes schedule compression, expediting fees, strained subcontractor relationships, and the compounding effect when a single rework event pushes long-lead equipment off the critical path.

To stop rework, project teams need to understand where it originates. Most of it does not start in the field.

Why construction rework is largely a documentation problem

The instinct in construction is to treat rework as a field execution issue. A crew installed it wrong. A sub used the wrong material. The workmanship was poor. These things happen, but they account for a smaller share of rework costs than most project managers assume.

Autodesk’s analysis of construction rework causes found that up to 70% of all rework in construction and engineering originates from design-induced errors, including incomplete drawings, conflicting specifications, and information that simply did not make it to the people who needed it. Miscommunication and poor project data alone account for 48% of rework on U.S. construction sites.

The implication is clear: most rework events are seeded in the pre-construction and early construction phases, long before a single tool is picked up on site. By the time the mistake becomes visible in the field, the decision that caused it was made weeks or months earlier.

The submittals gap: where specification errors reach the field

One of the most predictable paths from documentation error to field rework runs directly through the submittal process. Submittals exist precisely to intercept this problem. Before a piece of equipment is ordered, fabricated, or installed, the submittal review process is supposed to verify that the proposed product meets every technical requirement in the project specifications. When that verification works, non-compliant equipment never reaches the site. When it does not work, the consequences range from a rejected substitution late in procurement to a six-figure replacement after installation.

The process fails more often than it should. Industry data consistently puts first-round submittal rejection rates at 30 to 40% across commercial construction. Each rejected submittal adds at least two weeks to the review cycle for that item. For mechanical equipment on the critical path, those two weeks can cascade into month-long schedule impacts.

Part of the problem is the nature of the review itself. A single air handling unit submittal can contain 60 or more technical characteristics that need to be checked against plans and specifications. Refrigerant type, efficiency ratings, coatings, warranties, spare parts requirements, and dozens of other data points all have to be verified individually. A project engineer doing that review manually is working through dense product data sheets, searching spec sections, and cross-referencing drawings, often under schedule pressure that does not allow for the thoroughness the task actually demands.

Teams looking to address this systematically have turned to construction submittal software that performs the technical comparison automatically, extracting individual characteristics from submitted product data and checking each one against project specifications. Platforms built for this purpose flag failures, note ambiguous items that require human clarification, and provide source document references so reviewers can verify every determination before acting on it.

Key stat: Up to 70% of construction rework originates from design-induced errors, including incomplete drawings and conflicting specifications. The submittal review process is the last checkpoint before those errors reach the field.

The hidden cost multiplier: what rejection cycles actually cost

A single rejected submittal rarely stays contained. The direct cost is measurable: staff time to review the rejection, communicate with the subcontractor, wait for a revised package, and run the review again. But the indirect costs are often larger.

FMI’s analysis of design-driven rework costs shows that inaccurate or inaccessible information costs the U.S. construction industry approximately $31 billion annually. That figure reflects what happens downstream when information failures compound across a project.

Consider a mechanical submittal for a chiller unit rejected at the first-round review because the submitted refrigerant type does not match the specification. The PM flags it, returns it to the sub, the sub goes back to the manufacturer, a revised package is assembled and resubmitted. That cycle takes two to four weeks. If procurement cannot begin until approval is confirmed, and if the chiller is on the critical path, the schedule consequence is not two to four weeks on one line item. It is two to four weeks on commissioning, occupancy, and handover.

Multiply that pattern across a project with 500 submittals and an industry-average rejection rate of 35%, and you are looking at roughly 175 rejection cycles, each carrying direct administrative costs plus schedule risk. The aggregate is not a rounding error. It is a structural project cost that teams absorb because they do not have an efficient way to catch non-compliance before submittals leave the GC’s desk.

Catching the problem before it becomes a field problem

The most effective point to intervene in the rework cycle is the earliest one. That means the submittal review, not the field inspection.

A GC that reviews submittals thoroughly before forwarding to the design team accomplishes several things at once. It catches the product mismatches that would otherwise become rejection cycles. It gives subcontractors clear, specific feedback on what needs to change rather than a stamped rejection from the architect. It compresses the overall approval timeline by reducing back-and-forth with the design team. And it reduces the probability that non-compliant equipment reaches the site and gets installed.

Practically speaking, the challenge is capacity. A project with 500 to 2,000 submittals is not going to receive thorough manual review on every item when a PM is also managing RFIs, scheduling, subcontractor coordination, and dozens of other concurrent tasks. Review quality degrades under that pressure, and the items most likely to slip through are the complex ones where the gap between what was submitted and what was specified is subtle enough to miss without deep technical scrutiny.

What effective construction rework prevention looks like in practice

Teams that drive their rejection rates down significantly tend to share a common approach: they treat the GC’s preliminary review as the real technical checkpoint, not just a formatting pass before forwarding to the design team.

That means verifying technical characteristics against specifications at the product level, not just confirming that the right documentation was included. It means flagging items that are ambiguous or that reference outstanding RFIs before they go forward. It means giving project engineers a structured framework for what to look at on a given submittal type, so that review quality does not vary by how experienced the reviewer happens to be.

When that review layer works well, the design team receives submittals that have already been screened for technical compliance. The back-and-forth compresses. Approval timelines shorten. And the path from specification to installation carries far less rework risk.

Starting with the submittal process

Rework is not a single problem with a single cause. It comes from design errors, communication failures, documentation gaps, and execution mistakes, all interacting across a project lifecycle. But the submittal process is one place where a structured intervention can break the chain before it reaches the field.

A rejected submittal caught at the GC review stage costs a conversation and a resubmit. That same non-compliance caught at installation costs tearout, replacement, schedule compression, and the kind of rework cost that shows up in every post-project debrief as something that should have been caught earlier.

Getting the review right is not about adding process for its own sake. It is about using the time and attention available during pre-construction to prevent the far larger costs that surface when documentation errors reach concrete and steel.