IFC model exchange
The process of exporting a discipline's BIM model into the open IFC schema, checking what actually transferred, and importing it elsewhere without relying on a shared software licence.
What is IFC model exchange?
IFC model exchange is the practice of taking a model out of the software that created it and putting it into a neutral, structured file any other program can read on its own terms. Industry Foundation Classes (IFC) is the open schema behind this, maintained by buildingSMART and published as ISO 16739, describing walls, ducts, pipes and spaces as named, typed objects rather than lines and dumb geometry. Exchange is the verb, not the noun: export, mapping check, import, and round-trip test together confirm the receiving side got what the sending side meant to send.
On a residential project this happens at every handoff between disciplines that do not share a licence: architect to structural engineer, structural engineer to MEP coordination, and the whole coordinated set to the client's own archive at handover. Each handoff is only as good as the IFC file crossing it, because the receiving tool has no access to whatever stayed behind in the native format.
What actually survives an IFC export, and what does not?
An export is a translation, and translations lose things. A wall built from a parametric family becomes, on the other side of an export, a fixed piece of geometry tagged as a wall with a set of properties: it no longer remembers the rule that generated it, only the shape and the data attached at the moment of export.
| Usually survives | Usually does not survive |
|---|---|
| Overall geometry and spatial hierarchy (site, building, storey, space) | Native parametric rules (the family's driving dimensions and constraints) |
| Standard property sets mapped by the authoring tool (material, fire rating, thermal values) | Custom properties the tool never mapped to an IFC property set |
| Quantities the exporter calculates at export time (area, volume, length) | Formulas and live links driving those quantities |
| Object type and classification (wall, duct segment, space) | View-dependent 2D annotation: dimension strings, text notes, detail callouts tied to a specific drawing view |
A consultant receiving an IFC file cannot edit the design the way the author could; they can query it, measure it, run clash detection against it, and extract quantities, but not the parametric rules behind a stair or roof shape. Exchange is for coordination and record, not co-authoring.
Which IFC schema version should a residential project use?
The schema itself has versions, and the choice is not cosmetic.
| Version | Published | What it covers well | Practical note |
|---|---|---|---|
| IFC2x3 | 2005 | Buildings: architecture, structure, basic MEP | Still the most widely supported export and import target across older software versions; the safest default when a consultant's tool is unknown |
| IFC4 | 2013 | Buildings, richer property sets, better MEP systems and connections | A cleaner data model, but not every viewer or older tool reads it reliably |
| IFC4.3 (ISO 16739-1:2024) | 2024 | Buildings plus infrastructure such as roads, rail and bridges | Overkill for a single house; relevant once a project touches site infrastructure |
For a single-family or small residential project, IFC2x3 remains the pragmatic default for external exchange: it is the version every viewer, checker and older consultant tool still opens without complaint. IFC4 is worth insisting on once every party in the chain has confirmed clean export and import, since it carries structured MEP data more faithfully.
How is IFC model exchange different from sending a native project file?
A native file (.rvt, .pln, .skp) is a complete, editable copy of the author's project, but it opens correctly only in the tool that made it, often only a matching version. Sending it to a consultant who does not own that software sends them nothing they can open.
IFC exchange trades editability for independence: the receiving side gets a file any IFC-capable viewer can open, at the cost of the parametric intelligence described above. It also trades a licence dependency for a format dependency: a native file becomes unreadable once nobody in the project holds a current licence for that software, while an IFC file, an open ISO standard, stays readable regardless of which tools anyone still pays for.
The two are not competitors: native files for authoring inside one discipline, IFC exchange for anything crossing a discipline or software boundary.
What does a disciplined exchange workflow look like in practice?
A reliable workflow has four steps, repeated at each model issue rather than done once at the end:
- Export with a defined mapping. The authoring tool's IFC export settings decide which property sets, schema version, and level of geometric detail go out. Left at default, these vary by tool and version, so a project should fix them once and reuse them.
- Check the result before sending it. Open the exported file in a neutral viewer, not the authoring tool, and confirm spatial hierarchy, units, and coordinate origin match what the recipient expects. A model 40 metres from where it should be sits invisibly wrong until someone notices.
- Round-trip test on the first exchange of a project. Export, then re-import into a second instance of the source tool or a viewer, to confirm nothing silently dropped. Worth doing once per project, not once per file.
- Re-export at each model issue. Coordination is only useful if the file crossing the boundary is current; a stale export defeats the purpose of a shared Common Data Environment.
Why should a private client care about the exchange format?
Two consequences follow from choosing an open exchange format over native files. First, the client keeps a readable model after any one consultant's licence lapses, changes vendor, or the consultant is no longer available: an IFC file opens in free viewers years later, while a native file from an abandoned licence may not open at all. Second, each discipline keeps using the tool it is actually good at, because IFC is the common language between them rather than a shared program.
This is also what makes a usable as-built record possible: an IFC export of the coordinated model, alongside the drawings, is something a future maintenance contractor can open without owning or licensing anything.
What commonly goes wrong in an exchange, and how is it caught?
The recurring failure is not a corrupt file, it is a quiet mismatch: units exported in millimetres and imported assuming metres, a property the sending tool never mapped so the receiving side sees a blank field, or a geometric level of detail too coarse to support clash detection at all. None of these throw an error; they surface later, as a duct that "is not there" in the coordination model, or a fire rating that reads as unset.
The catch is procedural: someone opens the exported file independently of the tool that made it and checks it against a short list (origin, units, storey count, a few known dimensions), the same discipline behind a proper Level of Development declaration.
Where does IFC exchange sit in the wider coordination process?
Exchange is the mechanism, not the goal. It is what makes BIM coordination between separately licensed disciplines possible at all: without it, clash detection has nothing common to test, and a shared data environment has no neutral file to hold. Getting the settings, version choice and checking routine right once, early, is what lets every later step run on data everyone can actually open.
Frequently asked questions
- Do I need to buy separate software to open an IFC file?
- No. Several free IFC viewers exist that let anyone, including the client, open and measure a coordinated model without owning the authoring software. This is one of the main reasons the format is used for handover rather than a native file.
- Will an IFC export let me edit the design the same way the architect can?
- Not in general. Editing a parametric design at the level the original author can requires the native authoring tool. An IFC export preserves the shape and data but drops the underlying generative rules, so an IFC file is for checking, measuring, and coordinating, not for redesigning.
- Who decides which IFC version is used on my project?
- Typically the architect, as the party coordinating the model, sets the export version for the project and confirms every consultant's tool can actually open it before relying on it. It is a project decision, not a fixed technical requirement.
- Does an IFC export replace the drawings I need for a building permit?
- No. Permit and construction documentation still need to be issued as drawings under the applicable Slovak building regime. The IFC model is the coordination and record layer that sits behind those drawings, not a substitute for them.
- What should I ask my architect for at project handover?
- Ask for an IFC export of the coordinated model, not only the native file or PDFs, since the IFC file is what stays usable once nobody involved still holds an active software licence for the original tool.
- Can a small residential project skip IFC exchange and just share native files?
- It is possible when every consultant genuinely uses the same software and version, but that is rare once a structural engineer or MEP specialist is involved, and it leaves the client without a format-independent record at the end of the project.