IFC is an open file format for exchanging building models between different software. An IFC file carries geometry together with component information, so the recipient can read not only the shape but the type and attributes of every element within it.
When is IFC genuinely needed?
IFC exists for exchange, not for design development. Three conditions genuinely require it; outside them, working in the native format is usually more accurate and involves fewer steps.
- The parties involved run different software and cannot be consolidated, often because each is bound to its own corporate standard.
- The owner requires delivery in an open format so the data stays readable in future, regardless of what tool the provider used at the time.
- The model must be handed to an asset management system that does not read the modelling tool’s native format.
The second condition appears increasingly on government and institutional owner projects. The reasoning holds: buildings last decades, while software and suppliers change far faster. An open format protects the owner from dependence on a single tool ecosystem.
Where every discipline works in the same tool, adding an IFC export-import step lowers data quality without producing any benefit.
What survives and what is lost on IFC export?
This is the most misunderstood part. IFC export is not a copy of the model; it is a translation, and like every translation something does not carry across.
| Information type | Generally survives | Note |
| Component geometry | Yes | Shape and position carry across well |
| Element classification | Yes | Depends on the mapping defined at export |
| Custom attributes | Partly | Must be mapped deliberately; unmapped attributes vanish silently |
| Parametric behaviour | No | Elements become static for the recipient and cannot be driven parametrically |
| Annotation and drawings | Limited | IFC does not replace drawing documentation |
The most common misconception is treating IFC as an equivalent copy of the model. The practical consequence usually surfaces late: the recipient finds elements cannot be modified as they were in the source model, and concludes the file is broken — when that is simply how the format behaves.
The third row is the most dangerous because the loss is silent. An unmapped attribute produces no error message; it is simply absent in the recipient’s file, discovered only when someone looks for that information months later.
How do you prepare a good IFC export?
The four steps below run before the first delivery, not as repairs after the recipient complains.
- Agree the IFC version and data scope before the first file is sent, and record it in the BIM Execution Plan.
- Define which attributes must carry across, based on what the recipient genuinely needs.
- Check the export in the recipient’s tool, not only in the sending tool. A file that looks correct on one side may not read correctly on the other.
- Record the export settings so results stay consistent on every subsequent delivery, including when a different person runs it.
The first step decides the rest. Different IFC versions carry different data scope, and agreeing it after several delivery rounds means repeating the entire attribute mapping exercise.
How do you check the file before handover?
Four checks catch most problems, and all can be done without specialist tooling.
- Confirm the origin point and coordinates are correct, because an error here makes the model appear offset for the recipient — the same symptom as a failed federated model.
- Check element classification reads as intended rather than falling back to an uninformative generic category.
- Test that owner-required attributes are genuinely present, by opening one sample element of each type.
- Compare element counts against the source model to confirm no group dropped out during export.
The fourth check is the quickest and catches the largest problems most often. A significant count difference nearly always means one category failed to export because of a settings error, and that is far easier to fix before delivery than after the recipient has started using it.
Frequently Asked Questions
What is IFC?
IFC is an open file format for exchanging building models between different software. Unlike a plain drawing format, an IFC file carries geometry together with component information — element type and attributes — so the recipient can read its meaning, not only its shape.
Does IFC replace native formats?
No. IFC is for exchange and handover; design development stays in the tool’s native format. Working directly in IFC means losing the parametric behaviour that is the reason for using a modelling tool at all.
Are all IFC versions the same?
No. Different versions carry different data scope, so the version must be agreed at project start and recorded in the BIM Execution Plan. Agreeing it after several delivery rounds means redoing attribute mapping from scratch.
Can IFC files be edited?
Generally IFC is intended for exchange rather than design development. Elements within it become static and lose parametric behaviour. Changes should be made in the source model and re-exported, not edited directly in the IFC file.
Sources
- ISO 19650-4:2022 — Information exchange — https://www.iso.org/standard/78246.html
- ISO 19650-2:2018 — Delivery phase of the assets — https://www.iso.org/standard/68080.html
- ISO — Building information modelling (BIM), seri ISO 19650 — https://www.iso.org/sectors/building-construction/building-information-modelling
Get an Initial Consultation with BIMAGE Indonesia
BIMAGE Indonesia designs cross-discipline data exchange workflows, including scope definition and quality checking of handover files, as part of information management services certified to ISO 19650. If your project requires delivery in an open format, version and attribute mapping decisions belong before modelling starts — bring your handover requirements to an initial consultation.