Clash Detection Services: When You Need Them, and Who to Hire
A clash found on a screen costs an hour of somebody’s time. The same clash found on site costs a day of everybody’s.
I have lost count of the number of times I have been called to a site because a duct will not fit, a beam is fouling a riser, or a new steel frame has landed exactly where an existing drain run happens to be. Every one of those visits started the same way: with somebody saying the drawings were fine.
The drawings usually were fine. In isolation.
Clash detection exists because buildings are not designed in isolation. Structure, architecture, mechanical services, electrical containment, drainage and the ground itself are all modelled by different people, often in different offices, on different timescales. Clash detection is the process of bringing those models together and asking a blunt question: does anything here try to occupy the same space as anything else?
This guide covers what clash detection actually does, when in the programme it pays for itself, what it needs from your survey data, and how to choose a provider without ending up with a 4,000-item report that nobody reads.
What clash detection really is
At its simplest, clash detection is a geometric test. You federate the discipline models into a single coordinated environment, run a rules-based check, and get a list of intersections. Software does the arithmetic. The value is in what happens next.
Most people find it useful to think in three categories.
Hard clashes
Two objects occupy the same physical space. A duct passes through a column. A pipe runs through a structural beam. These are the obvious ones, and they are what most people picture when they hear the phrase.
Soft clashes, or clearance clashes
Nothing physically intersects, but the required tolerance around an object has been breached. A valve with no access zone. A luminaire with no maintenance gap. A riser that technically fits but leaves no room for insulation or for the person who has to install it. Soft clashes cause more site arguments than hard clashes, because they only become obvious once someone tries to do their job after some clashing component is already built.
Workflow or 4D clashes
Two elements do not conflict in space, but they conflict in time. The crane is where the scaffold needs to go in week 12. The slab is poured before the below-slab drainage is signed off. These clashes never show up in a purely geometric check, which is exactly why programme-aware coordination matters on constrained sites.
Reader tip
Hard clashes get fixed because they are undeniable. Soft clashes get argued about because everyone believes their own tolerance is the reasonable one. Agree clearance rules in writing before the first clash run, not after it.
Why so many clash reports get ignored
Here is the pattern I see on projects that have bought clash detection but are not getting value from it.
A federated model gets run with default settings. The software dutifully reports several thousand intersections. Nobody has time to triage several thousand anything, so the report is circulated, skimmed, and quietly filed. Three months later a duct will not fit.
The problem is not the software. It is that raw clash counts are meaningless without filtering, grouping and ownership. One duct passing through eight structural members can register as eight separate clashes, or as one design decision that needs making. A good coordinator gives you the second version.
Ask any prospective provider how they reduce a raw clash list into an actionable one. If the answer is vague, so will the report be.
When do you actually need clash detection?
Not every project needs a formal clash detection workflow. A single-storey rear extension with a boiler and a radiator circuit does not. Beyond a certain level of complexity, though, coordination stops being optional.
In my experience, the trigger points are these.
- Multiple design disciplines working in parallel. The moment structure, architecture and MEP are being developed by separate teams at the same time, you need a federation and checking process.
- Refurbishment and retrofit into existing fabric. This is where clash detection earns its keep hardest, because the existing building is the one thing nobody can simply redesign.
- Constrained plant rooms, risers and ceiling voids. Tight service zones are where clearance clashes concentrate.
- Below-ground works near live utilities. Buried services do not appear in an architect’s model unless somebody surveys them and puts them there.
- Off-site manufacture and prefabrication. Prefabricated modules and pre-cut service runs remove the ability to adjust on site, so the coordination has to be right before anything is fabricated.
- Phased occupation or live environments. Hospitals, schools and operational commercial buildings leave no room for improvised fixes.
If two or more of those apply to your project, coordination is not a nice-to-have.
Where clash detection fits in the programme
Timing determines value. Run it too early and you are coordinating placeholders. Run it too late and you are documenting problems rather than preventing them.
| Stage | What the clash run is for | What it needs from survey data |
|---|---|---|
| Feasibility and concept | Testing whether the intended massing and service strategy fit the constraints of the site and the existing structure | Topographical survey; outline measured building survey; known utility records |
| Developed design | First meaningful federation. Resolving strategic routing before it hardens into detail | Full measured building survey; point cloud of existing fabric; utility survey |
| Technical design | Detailed hard and soft clash resolution, tolerance checking, sign-off before fabrication | Verified as-existing model, correctly georeferenced to the project grid |
| Construction | Verifying as-built against as-designed, and coordinating temporary works and sequencing | Engineering surveys, setting-out checks, progressive scans |
The pattern to notice is that every row depends on survey data. Coordination is only as trustworthy as the model of reality it sits on top of, and that is the part of the process I get involved in most often.
Garbage in, garbage out: the survey data problem
This is the part of clash detection that gets least attention and causes most damage.
A clash detection exercise on a new-build greenfield scheme is a closed system. Every element is designed, so every element is in the model. Refurbishment is different. The existing building is not designed, it is discovered, and if it is discovered inaccurately then every clash result downstream inherits that error.
I have seen coordination run against a set of 1970s record drawings that were never updated. The federated model was immaculate. It was also wrong, because the actual slab levels varied from the drawings by enough to swallow an entire ceiling void. Nobody found out until the ductwork arrived.
Important
A clash report can only test the geometry you give it. If the as-existing model is based on old record drawings rather than a current survey, the software will confirm that your assumptions are internally consistent. It cannot tell you that your assumptions are wrong.
Three survey inputs do most of the heavy lifting for coordination on existing buildings.
3D laser scanning and point clouds
Scanning captures what is actually there, including the things nobody thought to record: the deflection in an old beam, the pipework added in 1998, the floor that falls 60mm across a plant room. A registered point cloud gives the design team a measured reality to coordinate against rather than an assumed one.
Measured building surveys and Revit models
A point cloud on its own is data, not a model. Converting it into a structured Revit model of the existing fabric turns it into something a coordinator can federate, filter and clash-test alongside the design models. Getting the level of detail right matters here, and it is worth agreeing explicitly at the outset: an over-modelled existing building wastes money, and an under-modelled one hides clashes.
Utility surveys
Below-ground clashes are the expensive ones, because they are usually discovered by an excavator. Utility surveys locate and map buried services so that foundations, drainage and new incoming supplies can be coordinated against what is genuinely underground rather than against a statutory record plan that shows a cable somewhere within a few metres.
There is a fourth requirement that cuts across all of these, and it is the one most often missed: georeferencing. If the survey, the design models and the site setting-out do not share a common coordinate system and a common project base point, the federation will report clashes that do not exist and miss ones that do. Insist that survey deliverables are supplied on the project grid, and confirm it in writing before work starts.
Not sure your existing-building data is good enough to coordinate against?
Terrain Surveys provides the as-existing data that clash detection depends on: 3D laser scanning, measured building surveys, Revit models and utility surveys, delivered on your project coordinate system. If you are planning a coordination exercise on an existing building, talk to us before the modelling starts rather than after the first clash report.
Who actually does clash detection?
Clash detection is not a single trade. Depending on the project, it may be delivered by any of several parties, and confusion about who owns it is one of the most common reasons it falls between the cracks.
The BIM coordinator or information manager
On larger projects there is usually a named individual or consultancy responsible for federating models, running clash tests, chairing coordination meetings and tracking issues to closure. This is the cleanest arrangement, because responsibility is explicit.
The MEP contractor or specialist subcontractor
Mechanical and electrical contractors frequently run their own coordination, particularly where they are producing installation drawings or procuring prefabricated modules. The strength is deep services knowledge. The limitation is that the focus tends to sit around their own scope.
The lead designer or architect
Some practices run coordination in-house. This works well where the practice has genuine BIM capability and enough resource to keep on top of it. It works badly where clash detection is a box-ticking exercise squeezed in around drawing production.
An independent BIM consultancy
Bringing in an independent party avoids the conflict of interest that arises when the people producing the models also mark their own homework. It costs more, and on complex or high-risk projects it is usually money well spent.
Where a survey consultancy fits
Terrain Surveys is a surveying consultancy, and clash detection is part of what we deliver: we build the existing-conditions model from measured survey; topographical surveys, measured building surveys, Revit surveys, 3D laser scanning, utility surveys. Then we run the clash detection against the design models and report what we find. Most of these projects run for months, with repeat site visits to scan, extend the model and re-check as construction progresses, and we verify on site that what was built matches what was coordinated.
What we don’t do is BIM coordination. Reviewing the clash reports, deciding which clashes matter and to whom, and driving them to resolution across the design team sits with your BIM coordinator, designer or contractor. We supply the measured reality and the clash evidence; they own the decisions made on the back of it.
How to choose a clash detection provider
What separates a useful coordination service from an expensive PDF? Ask these questions before you appoint.
- How will you triage the raw clash list? You want to hear about grouping, filtering by discipline pair, tolerance rules and severity ranking. Not a promise of thoroughness.
- Who owns each issue, and how is closure tracked? A clash is only resolved when someone has changed something and someone else has confirmed it. Ask to see the issue-tracking workflow.
- What clearance rules will you apply, and who signs them off? Access zones, insulation allowances and maintenance space should be agreed up front and documented.
- How do you handle the existing building? Ask specifically what they expect from survey data, what level of detail they need in the as-existing model, and what coordinate system they will work in.
- What software and exchange formats? Check compatibility with the whole team’s toolset, not just the largest consultant’s.
- What does the report look like? Ask for a redacted sample from a comparable project. Five minutes with a real report tells you more than an hour of discussion.
- How often will you run it? Coordination is a rhythm, not an event. Weekly or fortnightly cycles during technical design are common on busy projects.
- What happens on site? Find out whether anyone is verifying that the coordinated design was actually installed as coordinated.
Did you know?
A clash report with a low number is not automatically good news. It can mean the models were well coordinated. It can also mean the tolerances were set so loosely, or the model detail so coarse, that real conflicts were never tested. Always ask what settings produced the number.
What good coordination costs, and what it saves
Clash detection is one of the few construction services where the value case is straightforward to explain but awkward to prove, because success looks like nothing happening.
The cost side is easy enough. You are paying for coordinator time, software, the survey work that underpins the existing-conditions model, and the design team hours spent resolving what the reports find.
The saving side is harder to see, because it consists of variations that were never raised, rework that never happened, and programme delays that never occurred. That invisibility is precisely why coordination budgets get cut when a project comes under pressure, and why the cut so often shows up later as a site problem that costs several times more than the saving.
The comparison worth making is not clash detection against no clash detection. It is finding a problem in a model, where the fix is a design decision, against finding the same problem on site, where the fix involves a delivered component, an installed system, a subcontractor with other jobs booked, and a project that’s stuck.
Common mistakes to avoid
- Coordinating against record drawings on a refurbishment. Old drawings tell you what was intended, not what was built or what has been altered since.
- Leaving the coordinate system to chance. Different base points across disciplines will generate a clash list that is pure noise.
- Treating clash detection as a single milestone. One run at technical design catches a fraction of what iterative runs catch.
- Modelling the existing building to the wrong level of detail. Agree what gets modelled, and to what tolerance, before anyone starts.
- No named owner for issue resolution. Reports without accountability become archives.
- Stopping at handover of the design. Verifying as-built against the coordinated model is what protects you when something does not line up.
A practical sequence for existing buildings
If you are coordinating work into an existing building, the order of operations matters more than the software choice. This is the sequence I would suggest.
- Agree the project coordinate system and base point with every party, in writing.
- Commission the survey work: topographical for the site, 3D laser scanning and a measured building survey for the fabric, and a utility survey for anything below ground.
- Agree the level of detail for the as-existing Revit model, and what will be left as point cloud reference only.
- Federate the as-existing model with the design models and run a first coordination pass early, while routing decisions are still cheap to change.
- Agree clearance and tolerance rules, then run structured, filtered clash cycles with named owners and closure tracking.
- Freeze coordination before fabrication and procurement of anything prefabricated.
- Use engineering surveys and setting-out checks during construction to confirm that what is built matches what was coordinated.
Steps one to three are where the projects I see go right or wrong, long before anyone opens a clash detection package.
Get the as-existing data right before you coordinate
Since 2004 we have been surveying buildings and sites across England and Wales from our four offices in Welwyn, Rugby, Bristol and Sussex. If you need scan data, a Revit model of an existing building, or a utility survey to coordinate against, we can talk through what your design team will actually need.
Frequently asked questions
Is clash detection the same as BIM?
No. BIM is the wider process of creating and managing structured information about a building. Clash detection is one specific use of that information: testing federated models for spatial and clearance conflicts. You can do clash detection without a mature BIM process, and you can have a BIM process that never runs a clash test, though neither is ideal.
Do I need a point cloud, or is a measured building survey enough?
It depends on the complexity of the fabric and the tightness of the tolerances. For straightforward geometry, a conventional measured building survey may be sufficient. For irregular structures, tight service zones or anything where deflection and out-of-square conditions matter, scanning gives the coordination team a far more reliable basis. We are happy to advise on which is appropriate for a specific building.
Can clash detection find buried services?
Only if they are in the model, and they will only be in the model if they have been surveyed. Statutory record plans are useful as a starting point but are not survey-grade. A utility survey is what puts genuinely located below-ground services into the coordination environment.
How often should clash detection be run?
There is no single answer, but a regular cycle during technical design beats occasional large runs. Frequent, filtered checks keep the issue list manageable and stop problems compounding between reviews.
Who is responsible if a clash is missed?
That depends entirely on your appointments and contract documentation. It is worth establishing early who owns the coordination process, what the models are and are not warranted to represent, and how survey data is relied upon. Get it defined in the appointments rather than discovering the gap during a dispute.
Does Terrain Surveys run clash detection?
Our role is the survey side: producing the accurate, georeferenced as-existing data and models that coordination depends on, and verifying built work on site. The clash detection and resolution process itself normally sits with your BIM coordinator, lead designer or contractor.
The bottom line
Clash detection is not really about software. It is about deciding where you would rather find your problems.
Every project has conflicts in it. The only variable is whether they surface on a screen, where the fix is a design decision and an hour of someone’s time, or on site, where the fix is a variation, a delay and a difficult conversation.
Get three things right and the rest tends to follow: coordinate on a shared, verified coordinate system; base the existing-conditions model on current survey data rather than historic drawings; and give every clash a named owner and a closure date.
If you are about to start coordinating work into an existing building, start with the survey. Everything downstream depends on it.
