What IFC is, and why it sits at the center of BIM interoperability

IFC is the common language between BIM tools. Understanding what it carries, what it leaves behind and why there are so many versions settles most coordination arguments.

The scene repeats itself in every firm that starts working in BIM: the structural engineer asks for the model, someone exports an IFC, and two hours later a message arrives saying "the file opened wrong". The walls turned into blocks, the zones vanished, the model landed five hundred meters away from the origin — or none of that happened and the problem is a different one: it opened perfectly, but there is no information inside it.

Almost always, IFC is not the culprit. What is wrong is what people expect of it.

This article explains what IFC really is, what it can and cannot carry across, why so many versions are in circulation at the same time, and what to do in practice so that the file leaving your firm is usable on the other side.

What IFC is

IFC stands for Industry Foundation Classes. It is an open, neutral data schema for describing information about buildings and civil infrastructure, maintained by buildingSMART International, a non-profit organization that develops the industry’s open standards.

It is an international standard: the version in force is ISO 16739-1:2024, published in March 2024. In Brazil, ABNT published the national version, ABNT NBR ISO 16739-1, in December 2023.

The important word in that definition is schema, not format. IFC is not a "file format" the way DWG is. It is a dictionary of classes: it states that there is such a thing as an IfcWall, that it can have a height, a material, a relationship to a story, a fire rating property. Any software that understands that dictionary can read what another one wrote, without either of them having to open the other’s native format.

That is what the industry calls openBIM: collaborating through open standards instead of depending on everyone using the same software from the same vendor.

Interoperability is not "opening someone else’s file"

Here is the misunderstanding behind 90% of the frustration with IFC.

Interoperability does not mean the architect’s model becomes an editable model in the engineer’s hands, with every wall still parametric and ready to be changed and sent back. That is called a round-trip, and IFC was not designed for it. The IFC documentation itself says explicitly that this is not the scenario it covers.

What IFC does is transfer structured information in one direction: geometry, spatial hierarchy, element classification and properties, so that the other side can use it as a reliable reference for their own work.

In practice, when the structural engineer gets your IFC, what they need is to see where the walls are, to know that a wall is a wall and not a generic solid, to know which story it belongs to, and to check it against their beams. They do not need to edit your wall. If they do, the process is wrong, not the format.

The native model remains the original. IFC is the deliverable, not the working file.

The IFC versions, and why they affect you

This is the part that confuses people most, because official versions have been living side by side for almost twenty years.

Two points worth more than the whole table:

First: IFC2x3, from 2007, is still the most used. Not out of stubbornness. It is the version with the most mature implementation, the one tested across every piece of software on the market, and for a long time it was the only one with broad certification. If you do not know what the other side uses, IFC2x3 is still the safest bet. It is not the most modern one; it is the one least likely to break.

Second: IFC4.3 is the leap that matters if you work in infrastructure. It was approved as a final standard precisely because it extends the schema beyond buildings: roads, railways, bridges, ports and waterways. For a firm that only does buildings, there is less urgency. For anyone running road projects or working with public infrastructure agencies, it is what starts being required.

IFC5 is still in an exploratory alpha phase, and it is not a contract matter today. It is something to keep an eye on, not something to wait for.

In Archicad, the official documentation for version 29 confirms import and export support for IFC2x3, IFC4 and IFC4.3. So the version is your call, and it is a project decision: it follows from what the recipient can read, not from what is newest.

The files you will run into

The same IFC schema can be written in different encodings. The extensions are worth recognizing:

• .ifc: the most common one. Plain text, in the STEP format (ISO 10303-21). You can open it in a text editor and read it, which is extremely useful for diagnosing problems.
• .ifcZIP: the same file, zipped. That is all it is. It arrives much smaller by email.
• .ifcXML: an XML encoding. A much larger file, used in partial exchanges and integrations.
• ifcJSON: a JSON encoding, aimed at web applications. It is the natural route for the newer tools, including the ones that use AI.

If someone sends you an .ifcZIP and you think you cannot open it: you can. It is a zip file.

MVD: the detail that decides whether your IFC is any good

If there is one concept in this article worth keeping, it is this one. It is also the field most people skip in the export dialog.

MVD (Model View Definition) is an agreed subset of the IFC schema for one specific use. The full IFC schema is enormous and describes far more than any real exchange needs. The MVD defines what has to be present, what is left out, and how the concepts are applied in that kind of delivery.

In the Archicad export dialog, the three you will see most:

• IFC2x3 Coordination View: the most widely implemented of them all. Meant for sharing the model between architecture, structure and MEP: spatial structure, building elements and building service elements. It is the standard for classic coordination.
• IFC4 Reference View: built for reference model workflows, with the exchange going one way only. On export it simplifies: connections between walls and chained beams are left out. It is excellent for viewing, coordinating and clash detection; bad for anyone hoping to edit.
• IFC4 Design Transfer View: allows limited editing of the elements on the other side: inserting, deleting, moving and modifying elements and zones. It is the choice when the architect hands design data over for the engineer to work on top of. Even so, it is not made for round-tripping.

What usually goes wrong, and what causes it

Five problems explain nearly every IFC complaint that reaches us.

1. The elements arrive with no classification

A wall that exports as a generic solid is not an IFC failure; it is an element modeled with the wrong tool, or with the wrong class mapping. An object modeled as a Morph becomes geometry without meaning, unless someone classifies it explicitly. The rule holds: every element has to be what it is before it becomes IFC.

2. The geometry arrives, the information does not

Properties (the Property Sets, or psets) are what turns the model into a database. If nobody decided what to export, out comes a good-looking, mute model. And here the expectation has to be inverted: more information is not quality, it is weight. The right question is who will use that data on the other side, and that is exactly the level-of-information-need logic that ISO 19650 organizes.

3. The model opens far from the origin, or crooked

The project origin, the north direction and the coordinates have to be set and agreed before the first export. When each discipline sets its own, the federated model does not line up, and the problem only surfaces in coordination, late.

4. Every new export becomes a "new" model

Every IFC element has a unique identifier, the GUID. When it stays stable from one version to the next, the coordination tool can tell what changed between deliveries. When it does not, every round looks like a whole new model and the comment history is lost.

5. Each discipline exports its own way

This one is not a technical problem, it is a process problem. Without a written agreement on version, MVD, properties and naming, every delivery is a fresh negotiation. That agreement is the BIM Execution Plan, and it is the difference between coordinating and improvising.

The ecosystem around IFC

IFC does not work alone. Three open buildingSMART standards show up alongside it and are worth knowing by name:

• IDS (Information Delivery Specification), published as a final standard in version 1.0 in June 2024. It is a file that describes, in a machine-readable way, what has to be in the model: which objects, with which properties, within which value ranges. With it, checking stops being a visual review and becomes automatic. For a firm it is the most important standard of recent years, because it turns a requirement into a test.
• BCF (BIM Collaboration Format), created in 2009. It carries the problem, not the model: a comment tied to a viewpoint, an image and the element’s GUID. It is what replaces the PDF with the little red cloud drawn on it.
• bSDD, the buildingSMART Data Dictionary, which standardizes classifications and properties across countries and systems.

IFC in Brazil

Two hard facts, for anyone who has to make the case to a client or answer a public tender.

The standard exists in Portuguese: ABNT NBR ISO 16739-1, published on 29 Dec 2023.

If your firm works, or wants to work, on public projects or for large developers, delivering a well-organized IFC has stopped being a differentiator and become an entry requirement.

An export checklist that covers most of the cases

Before you send the file:

1. Agree the version and the MVD with whoever is receiving it. One question by email saves two days.
2. Check that every element is classified as what it is. Generic solids are defect number one.
3. Set the origin, the north direction and the coordinates before the first delivery, not after.
4. Choose which properties to export, instead of exporting everything or nothing.
5. Open the IFC you have just generated in a free viewer (BIMcollab Zoom, usBIM.viewer, Solibri Anywhere) before you send it. You see what the other person will see. That step alone heads off most of the emails coming back.
6. Save the export settings as a profile in the firm’s template. As long as each architect exports their own way, the result is unpredictable by definition.

Step 6 is what separates a firm that suffers with IFC from a firm that no longer thinks about it. Export settings belong to the firm, not to whoever happened to learn them first.

The bottom line

IFC is not perfect, and it does not fix a bad process. It is a common language, and a common language only works when both sides agree on the subject before they start talking.

Most of the problems we see during an implementation are not the file: it is that nobody decided which version, which subset, which properties, and who any of it is for. Decide that once, write it into the template and into the execution plan, and IFC drops off the firm’s list of worries. Which was the whole point from the start.

Frequently asked questions

What does IFC stand for?

Industry Foundation Classes. It is an open, neutral data schema for information about buildings and civil infrastructure, maintained by buildingSMART International and standardized as ISO 16739-1:2024. In Brazil it exists as ABNT NBR ISO 16739-1.

What is the difference between IFC and the software’s native file?

The native file is the working file, with all of the software’s parametrics. IFC is the deliverable: a structured description of what was designed, readable by any software that follows the standard. One does not replace the other.

Can you edit an IFC and send it back to whoever sent it?

That is not what it is for. IFC was not designed for round-trip exchange. There is limited editing in IFC4 Design Transfer View, but the official documentation is explicit that this is not a round-trip scenario. The native model remains the source.

Which IFC version should I use?

Whichever one the recipient can read properly. When in doubt, or with nothing to go on, IFC2x3 Coordination View is still the safest bet, because its implementation is the most mature. IFC4.3 is the current version of the standard and the route for infrastructure.

Does Archicad export IFC?

Yes. The official Archicad 29 documentation confirms import and export in IFC2x3, IFC4 and IFC4.3, with translator settings that define the MVD, the class mapping and the properties exported.

Why does my IFC open with no information at all?

Because the information is exported by the translator settings. If nobody defined which properties should go out, only the geometry goes out. It is a setting, not a limit of the format.

Is IFC mandatory in Brazil?

Decree 10,306/2020 requires, in the federal public contracts it reaches, that the files be delivered in an open (non-proprietary) format, without naming IFC in the text. In practice, for a BIM model that open format is IFC, and the agencies’ technical documents ask for it by name.

Sources

1. buildingSMART Technical, Industry Foundation Classes (IFC) and IFC Schema Specifications, with the versions, dates and matching ISO standards.
2. ISO 16739-1:2024, edition 2, published in March 2024.
3. buildingSMART International, IFC 4.3 approved as a final standard.
4. buildingSMART, Learn IFC 5 with us, on the IFC5 alpha phase.
5. ABNT NBR ISO 16739-1, published on 29 Dec 2023. Entry in the Target catalog.
6. buildingSMART Technical, Model View Definitions (MVD).
7. Graphisoft Help, Model View Definitions and Working with IFC (Archicad 29).
8. buildingSMART Technical, Information Delivery Specification (IDS) and BIM Collaboration Format (BCF).
9. Decree 10,306/2020, art. 6, item II.

Published 23 Sep 2026 · Updated 23 Sep 2026