Clash detection in BIM is the automated process of checking combined 3D models from different disciplines to find where building elements physically conflict or violate clearance rules. It runs before construction starts, flagging issues like a duct passing through a beam so design teams can resolve them on screen instead of on the job site.

On a mid-size building, the architectural, structural, mechanical, electrical, and plumbing models are usually built by separate teams in separate files. Each one looks correct on its own. The trouble appears when they are stacked together, because two disciplines often claim the same physical space. Clash detection is how project teams catch those overlaps early, when fixing them costs a few hours of modeling rather than weeks of demolition and rerouting.

How does clash detection work in BIM?

Clash detection works by merging individual discipline models into a single federated model, then running geometric and rule-based checks that compare every element against the others. The software reports each conflict as a clash, gives it a location and a 3D snapshot, and groups the results so coordinators can review and assign them.

The federated model is the foundation. Instead of editing one master file, each team keeps authoring in its own tool, then exports a copy for coordination. Those copies are loaded together so the structural steel, the supply ductwork, the sprinkler lines, and the partition walls all appear in the same coordinate space. From there the clash engine does the heavy lifting, testing thousands of element pairs in minutes and listing only the ones that actually touch or crowd each other.

Most teams run clashes by selection sets rather than checking everything against everything at once. A typical test pairs structure against mechanical, or mechanical against plumbing, so the results stay focused and easy to assign to the right trade. Each detected clash carries enough data, such as element IDs and grid location, that a reviewer can jump straight to the problem in the model.

The three types of clashes you will find

Not every clash is the same problem, and treating them all as equal wastes coordination time. Clash detection software generally sorts conflicts into three categories, each with a different cause and a different fix.

Hard clashes

A hard clash happens when two components occupy the same physical space, such as ductwork running straight through a structural beam or a pipe crossing a wall opening that was never planned. These are the most obvious conflicts and usually the highest priority, because the building literally cannot be built as drawn. Hard clashes are detected purely from geometry, so the software finds them with high reliability.

Soft clashes

A soft clash is a clearance or tolerance problem rather than a direct collision. Two elements do not touch, but one sits too close to the other to allow for insulation, maintenance access, or code-required service space. An air handling unit installed with no room to swing its access panel passes a hard-clash test yet fails the real world. Catching soft clashes depends on setting sensible clearance rules before you run the check.

Workflow or 4D clashes

A workflow clash, sometimes called a 4D clash, is a scheduling conflict instead of a spatial one. Two activities are planned in a way that cannot physically happen in sequence, such as pouring a slab before the conduit beneath it has been installed. These surface only when the model is linked to the construction schedule, which is why 4D coordination has grown alongside basic geometric checking.

Why is clash detection important?

Clash detection matters because conflicts caught in the model cost almost nothing to fix, while the same conflicts caught on site trigger rework, change orders, and schedule delays. Moving a clash from the field to the screen is the core value, and it compounds across every trade on a project.

The data backs this up. In the 2021 SmartMarket Report on BIM and digital transformation by Dodge Data and Analytics, 40 percent of contractors with very high BIM engagement said BIM significantly reduced rework on their projects, which they tied directly to cost savings. Spatial coordination, the category that clash detection belongs to, consistently ranks among the most-used BIM workflows in those surveys precisely because the payback is easy to see.

There is a quieter benefit too. When trades trust that the model is coordinated, they prefabricate more components off site, which is faster, safer, and tighter on quality. That confidence only exists if clash detection has been run and the results have been resolved and documented.

The clash detection workflow step by step

A coordination cycle follows a repeatable loop. Teams usually run it on a fixed rhythm, often weekly, so issues never pile up to an unmanageable size.

1. Export and federate: Each discipline exports its current model, frequently as IFC for openBIM projects, and the coordinator loads them into one combined model.
2. Run clash tests: Tests are set up by pairing selection sets, such as structure versus mechanical, with the right clash type and tolerance for each pair.
3. Review and group: The coordinator filters the raw results, groups related clashes, and dismisses geometry that is intentional or already resolved.
4. Assign and communicate: Real issues are turned into trackable items and sent to the responsible team, commonly using the BIM Collaboration Format so the comment, view, and status travel together.
5. Resolve and re-run: Teams update their models, and the next coordination cycle confirms the fix and catches anything the change introduced.

The communication step is where projects either stay organized or fall apart. A clash that nobody owns is a clash that survives to the site. Tying every issue to a named team and a clear status is what turns a long list into actual progress.

Which software runs clash detection?

The best-known tool is Autodesk Navisworks Manage, whose Clash Detective feature combines models from multiple disciplines and runs rule-based checks against them. You can read the feature documentation on the official Autodesk Navisworks help page for the Clash Detective tool. Navisworks acts as an aggregator, pulling in models that were authored elsewhere, which is why authoring tools and coordination tools usually stay separate.

Most architectural models that feed into a clash workflow start in Autodesk Revit, and studying fully developed, construction-ready Revit models is one of the faster ways to understand how clean authoring reduces clashes downstream. On openBIM projects the coordination happens through IFC files and is communicated using the BIM Collaboration Format maintained by buildingSMART, which links each clash location to a comment, a status, and a responsible party.

Comparison of clash types and how to handle them

The table below summarizes how the three clash categories differ in cause, detection, and priority during coordination.

Clash type	Cause	How it is detected	Typical priority
Hard clash	Two elements share the same physical space	Pure geometry intersection test	High, blocks construction
Soft clash	Insufficient clearance, access, or tolerance	Clearance rule with a set buffer distance	Medium, affects operation and maintenance
Workflow (4D)	Activities sequenced in an impossible order	Model linked to the construction schedule	Varies, drives site logistics

When should clash detection start on a project?

Clash detection should begin as soon as two coordinated models exist, not at the end of design. Running an early, rough check on structure against architecture catches layout problems while they are still cheap to move. Waiting until documentation is nearly complete means every clash is now tangled in finished drawings, schedules, and specifications.

The most useful pattern is regular and incremental. A short weekly cycle on a growing model keeps the issue count manageable and builds a habit across every team. A single massive check the week before tender almost always produces a list too large to resolve in time, which defeats the point of modeling in the first place.

Frequently asked questions

Is clash detection the same as BIM coordination?

No. Clash detection is one step inside BIM coordination. Coordination is the broader process of combining models, running checks, communicating issues, and tracking them to resolution. Clash detection is specifically the automated check that finds the conflicts; the rest of coordination is what gets them fixed.

Do I need Navisworks to detect clashes?

No. Navisworks Manage is the most common dedicated tool, but Revit can run interference checks within its own models, and several openBIM coordination tools detect clashes directly from IFC files. The right choice depends on whether your teams share native files or work in an openBIM exchange.

What is a federated model?

A federated model is a combined view that loads each discipline's model together in shared coordinates without merging them into one editable file. Every team keeps ownership of its own model, and the federated version exists only for review and clash detection.

How many clashes is normal on a project?

Raw clash counts can run into the thousands or tens of thousands on complex buildings, which sounds alarming but is expected. The meaningful number is the count of grouped, valid issues after filtering, which is usually far smaller and is what coordinators actually work through each cycle.

Technical specifications such as clearance tolerances should be verified by a licensed professional for your specific project, since required service zones and code clearances vary by building type and jurisdiction.

Putting It All Together

Bottom Line: Clash detection in BIM is the automated check that finds where building systems collide or crowd each other before anyone breaks ground. Sort the results into hard, soft, and 4D clashes, run the check early and on a regular cycle, and tie every real issue to a named team through a tracked format so the model stays a coordination tool rather than a pile of unresolved conflicts.