A project has three disciplines. Architecture works in Revit. Structural steel works in Tekla. The infrastructure package works in Civil 3D. At the coordination meeting, all three have to look at one model.
Nobody changes software. Nobody sends their native file either, because the others cannot open it. What gets sent is an IFC file.
This is a reference article about a format, and it does not lead to any course. It answers four questions. What is IFC, and who maintains it? Why are there several versions? What survives an export to IFC, and what is lost? And when should you send the native file instead?
If BIM itself is new to you, read What is BIM? first, since IFC only means anything once a model exists.
What IFC is
IFC stands for Industry Foundation Classes. It is an open format that describes a construction work as data, used when a model has to move between different software.
The standard is maintained by buildingSMART. According to their official documentation, IFC is "a standardized, digital description of the built environment, including buildings and civil infrastructure". The same page states that it is "an open, international standard" and "vendor-neutral". The standard is registered internationally as ISO 16739-1.
Those three characteristics explain why IFC exists at all.
Open means the specification is public and anyone can see how the data is organised. You do not buy a licence in order to understand the file.
Vendor-neutral means Autodesk, Trimble and Graphisoft all read and write it, and none of them owns it. That is the fundamental difference from a native file: a Revit .rvt opens only in Revit, while an .ifc opens almost anywhere.
Described as data, not as pictures means a wall in an IFC file is not a set of lines. It is an object declared as a wall, with a thickness, a material, a storey it belongs to, and an identifier of its own.
Working this way, on open standards, is usually called openBIM. The opposite is staying inside one vendor's closed set of tools.
IFC versions and the ISO 16739 standard
This is where two parties exchanging files most often get confused.
IFC2x3 dates from 2007 and covers buildings. It remains the version software supports most reliably, and many projects still default to it for exactly that reason.
IFC4 is its successor, corresponding to ISO 16739-1:2018, with better geometry and property handling.
IFC4.3 is the current version, ratified by ISO in early 2024 as ISO 16739-1:2024. Its significance is the extension into infrastructure: bridges, roads, railways, waterways and ports, along with a way to describe alignments. Until then IFC was built around buildings, so infrastructure data had nowhere proper to sit. Infrastructure BIM versus building BIM covers the difference between the two fields.
Beyond version numbers there is one more term worth knowing: the model view definition, which states how much of the schema goes into a given export. Two IFC2x3 files exported under different definitions carry different content. The most widely certified one is Coordination View 2.0, meant for cross-discipline coordination.
The practical consequence: when a project agrees to exchange in IFC, it must state the version and the export scope. "Send me the IFC" is not a specification.
Exporting to IFC: what survives and what stays behind
This is the most important section of the article, and the one most often misunderstood.
Five things survive. The shape and position of each object. What kind of object it is. Its attached properties such as material, size and reference. Its relationships, meaning which storey and which space it belongs to. And a unique identifier for every object.
That identifier is the part people undervalue. It is what lets a clash detection tool point at exactly which pipe hits which beam. It is also what keeps last round's comments attached to the right object in the next export.
What stays behind is everything that made the model editable. Parameters driving the geometry do not travel. Constraints and modelling relationships do not travel. Nor does the source family you would need to create a new type. An IFC file is a record of the result, not a source file to keep working in.
Understanding that avoids two common mistakes.
The first is opening the IFC, editing it directly, and treating the model as updated. The sender then updates their own file and re-exports, and your edits are gone.
The second is accepting IFC as the only handover format when the contract still requires later changes. The receiving party ends up with a model they can look at but cannot develop.
When to use IFC and when to use the native file
There is a short way to decide: use IFC when the recipient only needs to read the model, and the native file when they need to keep working on it.
Work that suits IFC: federating discipline models for clash detection; sending a model to a checker or the client to look at; long-term archiving; feeding quantity take-off software. What is Cubicost? is an example of the last one, a measurement suite that takes models in through IFC.
Work that needs the native file: two parties building one model together; handing over to whoever continues the next stage; anything that means editing parametric geometry.
In practice most projects do both. Each discipline keeps and works in its own native file, while IFC exports go up to the common data environment on a set rhythm for everyone else to read. That rhythm and the IFC version in use belong in the BIM execution plan.
openBIM and IFC on Vietnamese projects
On the standards side, Vietnam has adopted the ISO 19650 set as TCVN 14177-1:2024 and TCVN 14177-2:2024. That set governs how information is managed across the life of an asset; it does not prescribe a file format. The national BIM standards are still being extended: a draft standard on level of information need is out for public comment this year.
On the legal side, Decree 217/2026 makes BIM mandatory for new works of grade II and above, but names no file format. It does place responsibility for setting up and running a common data environment on the client for grade-I works within publicly funded projects.
So in practice, the requirement to use IFC comes from the contract and the project's BIM execution plan, not from a blanket regulation. Any project where several parties work in different software will almost certainly ask for it.
Three questions worth asking when a project settles on IFC. Which version, IFC2x3 or IFC4 and above? Exported under which scope? And what will the recipient open it in, since the same file can display slightly differently in two applications?
Frequently asked questions
What is IFC in one sentence?
An open format describing a construction work as data, registered internationally as ISO 16739-1, used when a model has to be exchanged between different software.
Does exporting to IFC lose information?
Yes, deliberately so. Geometry, object classification and properties travel with the file. Modelling parameters, constraints and source families do not. An IFC file records the result for reading, not the source for further editing.
Which IFC version should I export?
Whichever the project agreed on. Without an agreement, IFC2x3 under Coordination View 2.0 is the safest for being readable everywhere. Infrastructure projects need IFC4.3, because earlier versions have nowhere to describe an alignment.
What opens an IFC file?
Model federation and checking tools such as Navisworks, Solibri or Trimble Connect, or the authoring software itself. For viewing alone, several free IFC viewers exist.
Can IFC replace drawings?
Not entirely in Vietnam yet. Decree 217/2026 allows a BIM model to stand in for paper design documents with equivalent legal weight, but only where the authority has the infrastructure, the people and the technology to receive it.