IFC Explained: What It Actually Is (and Why It's Not Just a File Format)

A deadline is looming, you need to share your model with a consultant. You hit "Export to IFC," send the email, and wait for the all-clear. Instead, you get a frantic call ten minutes later: the walls lost their intelligence, the mechanical equipment vanished, the geometry got reduced to "dumb" extrusions.

What is IFC, if not a file format?

Most AEC professionals treat IFC as a simple file extension, a digital container like a PDF or a JPEG. In reality, Industry Foundation Classes is a complex, object-oriented data schema: a global language, developed by buildingSMART, designed to describe the actual DNA of the built environment.

When you hit "Export," you're not just saving a file, you're attempting a high-stakes translation of data. If you don't understand the language, the model getting lost in translation shouldn't be a surprise.

FACT 1
What are the four layers of the IFC schema?

The IFC schema is structured like an onion, moving from universal abstractions to discipline-specific details, where each layer builds on the one below it:

FACT 2
Why does "round-tripping" IFC always seem to fail?

Because it's asking the schema to do something it was never designed for. One of the most common mistakes in BIM strategy is attempting to "round-trip" a file, exporting from one platform, editing in another, bringing it back for further design. When that fails, teams blame the format. The real issue: IFC (particularly the widely-used IFC2x3) is built as an exchange format, not a design transfer format.

Software-specific logic, like how a platform calculates a wall join or a hosted family, can't always be recreated from a generic schema meant for one-way exchange. IFC is the source of truth for what's in the building, not a bridge for multi-platform co-authoring.

FACT 3
What makes an IfcWall smarter than a shape?

In standard CAD, a wall is just lines. In a basic 3D format, it's an extrusion. In IFC, that wall is an IfcWall, a specific Class carrying real object-oriented intelligence.

A proper IFC Class ensures an object "knows" its own dependencies. An IfcWall doesn't just look like a wall, it knows it must carry height, width, layer thickness, and material data. It understands it can host doors and windows, and that it's vertically constrained by base and top levels.

FACT 4
Why do exports turn into a generic "Proxy," and how do you prevent it?

If an interoperability strategy begins and ends with clicking "Export," the data is already at risk. Out-of-the-box mapping only covers a small fraction of real project scenarios, variations in something like "Mechanical Equipment" are far too complex for default settings to handle.

When mapping is ignored, objects default to the closest thing IFC has to a bad word: IfcBuildingElementProxy. It tells the recipient the object exists, but gives zero intelligence about what it actually is.

Avoiding the Proxy problem requires Parameter Overriding at the element level:

• IfcExportAs - overriding the default IFC Class (e.g. ensuring a custom MEP component exports as an IfcUnitaryEquipmentType)
• IfcExportType - defining the specific sub-category (e.g. a radiator exporting as SECTIONALRADIATOR rather than a generic heater)

FACT 5
What's coming with IFC5?

The schema isn't a static relic, it's undergoing active modernization. IFC5 (currently in development, with active work ongoing through 2026) is moving toward a modular, "late binding" structure, away from the current monolithic, rigid schema.

The goal: make the schema modular and easier to extend, so different domains (like Rail and Architecture) can achieve seamless interoperability without needing a total schema overhaul. This should let software vendors implement incremental updates, so the schema can evolve as fast as the technology it supports, better suited to the data-heavy demands of digital twins and automated fabrication.

Conclusion: the foundation of interoperability

IFC is the digital language of the industry, a bridge spanning from the basics of measurement and geometry to the discipline-specific data of tunnels, roads, and skyscrapers. As construction moves toward a more data-centric future, IFC deserves to be treated as project infrastructure, not a file conversion checkbox.

Frequently asked questions