Why Your Consultant's IFC Export Looks Wrong (and How to Check It Yourself)
You open the IFC, and something is off. The model loads a kilometre away from where it should be. Or a cluster of elements hovers in space far from the building. Or you click a wall and the properties panel is nearly empty. Or the file that should federate neatly with the other disciplines lands rotated, offset, or apparently duplicated.
The reflex response — "the IFC format is broken" — is almost always wrong. IFC is a faithful messenger; the problems travel into the file from how the model was authored and exported. The good news is that the failures are stereotyped: the same five problems account for the overwhelming majority of "your model looks wrong" emails, each has a recognisable signature, and you can diagnose all of them yourself in a free browser viewer before writing that email — which transforms the conversation from "it looks wrong" to "your export uses local coordinates instead of the shared site point; please re-export with these settings."
Here's the field guide.
1. The model loads in the wrong place
Signature: the model appears at a huge distance from the origin, or disciplines that should overlap land far apart when viewed together.
What actually happened: coordinates. Every model has an internal origin, and projects define a shared site point so that all disciplines align. If one consultant exports relative to their file's internal origin while everyone else uses the shared coordinates — or someone models real-world map coordinates directly, putting geometry millions of millimetres from origin — the exports disagree. IFC can also carry formal georeferencing (a map conversion defining how the model relates to a projected coordinate system), and an export that omits or mangles it strands the model in space.
How to check: open the model in the BIM Model Viewer and select a known reference element — a grid intersection column, the survey point. Read its coordinates in the properties and compare against the project's agreed site point. Wildly large values suggest map coordinates modelled directly; values near zero when the project expects site coordinates suggest an internal-origin export.
The fix to request: re-export using the project's shared/site coordinate setup, and state the agreed base point in your request so there's no second round.
Pro tip: Coordinate agreements belong in writing before the first exchange — the BIM execution plan should name the project base point, orientation (true north vs project north), and units. Half the coordinate chaos on projects traces to this paragraph never having been written.
2. Elements floating in space
Signature: the building looks right, but stray geometry hovers hundreds of metres away — a lonely door, a fragment of pipe, furniture in orbit.
What actually happened: authoring debris. Elements accidentally copied far off-site, content placed on the wrong level and never cleaned, or reference geometry that should have been excluded from export. Every floater inflates the model's bounding box, which is why the viewer zooms to show your building as a speck.
How to check: in the viewer, use the spatial tree to hide the building storey by storey — whatever remains visible is the debris. Click each floater and read its identity: element type, name, and containing storey tell the author exactly what to delete.
The fix to request: clean-up and re-export, with your list of offending elements attached. Specific lists get fixed; "there's stuff floating" gets debated.
3. Missing or empty properties
Signature: geometry is fine, but clicking elements shows bare-bones data — no fire ratings, no classifications, none of the property sets the deliverable requires.
What actually happened: the export settings, almost every time. IFC exporters let the author choose which property sets (Psets) to include, and the default configuration frequently excludes custom parameters. The data usually exists in the authoring model; it simply wasn't invited to the export. Occasionally the gap is real — the parameters were never filled — which is a different, larger conversation.
How to check: sample elements across several categories and compare what appears against the project's information requirements. If standard Psets appear but project-specific ones don't, it's export settings. If even basics are absent, suspect the source model.
The fix to request: re-export with property sets (including custom/shared parameters) enabled — and if your project defines information requirements formally, cite the exact clause. This failure mode is precisely why machine-readable specifications like IDS exist: requirements you can check automatically instead of by sampling.
4. Wrong or missing elements
Signature: whole categories absent (no ceilings, no rebar, no site), or conversely a bloated file full of content nobody asked for.
What actually happened: the export scope. Exporters filter by view, phase, and category — export from the wrong view or phase and you get that view's visibility, not the deliverable's requirements. The Model View Definition (the standard "flavour" of IFC chosen at export, such as Coordination View) also legitimately shapes what's included; a coordination-oriented export is not a fabrication-detail export.
How to check: walk the spatial tree in the viewer against a mental (or written) checklist of expected categories per discipline. Absences are obvious in seconds this way — far faster than orbiting the 3D view hoping to notice what isn't there.
The fix to request: re-export from an agreed export view whose scope matches the deliverable, and record that view name in the BEP so the next exchange starts right.
5. Duplicates
Signature: the model looks subtly "heavy"; selecting an element highlights one of two identical copies in the same place; quantity extractions come out roughly double for some categories.
What actually happened: linked files exported twice (once as a link, once merged), copied elements in the source model, or a federation that includes the same discipline model under two names. Duplicates are the quiet killer because the model looks correct — the copies coincide perfectly — while any count, schedule, or clash run built on it inherits the doubling.
How to check: click suspicious elements and read identities — coincident copies reveal themselves as two distinct elements at one location. If a spot-check finds even one true duplicate, treat the whole file as suspect and escalate to a systematic check rather than hunting duplicates one by one.
The fix to request: source-model clean-up, and a statement of which linked models were included in the export.
The ten-minute triage, assembled
Before replying to any "here's our IFC" email, run the sequence: load → check a known element's coordinates → hide storeys and hunt floaters → sample properties in three categories → walk the tree for missing scope → spot-check for duplicates. Ten minutes in a browser viewer, no licences involved, and your response email carries diagnoses instead of complaints — which, on a live coordination cycle, is the difference between one re-export and three.
For the viewer basics behind these checks — navigation, the spatial tree, properties, sections — start with how to open an IFC file without Revit.
Open the BIM Model Viewer → — free, no install, and the consultant's model never leaves your device.
Model checks in a viewer identify symptoms; responsibility for model content remains with the originating author. For contractual deliverable acceptance, verify against the project's documented information requirements.