IFC vs Proprietary Formats: Why Open BIM Will Win (Eventually)

The File Format Cold War

Every week at Sasez GmbH, we ran the same coordination ritual. The architect sends a .rvt file. The structural engineer sends a .dwg. The MEP team (us) sends another .rvt. The facade consultant sends an .ifc. And the project manager opens each one in a different viewer, squinting at clashes that may or may not actually exist.

This is the reality of BIM coordination in 2025. We have a universal standard — IFC — that's supposed to solve interoperability. And we have proprietary formats — RVT, DWG, PLN — that actually contain the data people need.

After 3+ years of daily BIM work, I've come to a conclusion: IFC will win eventually. But "eventually" might be a decade away, and the path there is messier than most BIM evangelists admit.

What IFC Actually Is

IFC — Industry Foundation Classes — is an open, ISO-standardized data model for describing building and construction data. The current version is IFC4 (ISO 16739-1:2018), with IFC4.3 extending coverage to infrastructure (bridges, roads, railways).

At its core, IFC is a schema. It defines entities like walls, duct segments, spaces, and the relationships between them. An IFC file is a serialized graph of these entities, typically in STEP format (.ifc) or increasingly in XML (.ifcXML).

The format isn't pretty to look at — it's a dense, machine-oriented text format where every building element is represented as a numbered entity with references to other entities. But it's universal. Any BIM software that implements the IFC schema can read it.

Where IFC Works Today

IFC excels in scenarios where data exchange doesn't need to be round-trip:

Regulatory Submissions

In Germany, many building authorities now accept or require IFC files for building permit applications. The model is submitted as a snapshot — nobody needs to edit it further. IFC handles this well.

Model Checking

Tools like Solibri and SimpleBIM consume IFC files for automated rule checking. Does every room have a fire exit? Are all corridors wide enough for wheelchair access? Is the ventilation duct clearance sufficient? These checks work on the IFC data model and don't need parametric editing capability.

Archiving

IFC is an ISO standard with a 20+ year track record. When you need to archive a building model for the next 50 years, betting on a proprietary format that might not exist in 10 years is risky. IFC is the safe bet.

Multi-Vendor Projects

When the architect uses ArchiCAD, the structural engineer uses Tekla, and the MEP team uses Revit, IFC is the only common language. It's imperfect, but it's the only game in town.

Where IFC Still Fails

And now for the hard truths.

Round-Trip Editing Is Mostly a Myth

The promise of "open BIM" is that you export IFC from one tool, edit it in another, and import the changes back. In practice, this almost never works cleanly.

When you export a Revit model to IFC, you lose:

  • Parametric relationships (a wall height tied to a level)
  • Family definitions (the "intelligence" of Revit components)
  • MEP system connections (which duct connects to which air handling unit)
  • View-specific settings and annotations
  • Scheduling and quantity data tied to Revit parameters

You get geometry and basic properties. That's useful, but it's not a working model.

MEP System Fidelity Is Poor

This is my specific pain point as an MEP engineer. IFC can represent HVAC systems — ducts, pipes, fittings, terminals, distribution systems. In theory, you can fully describe a duct network.

In practice, the export quality depends entirely on the authoring tool's IFC exporter. Revit's IFC export for MEP systems has improved significantly since 2020, but I still regularly encounter:

  • Missing system assignments. Duct segments exported without their distribution system relationship, making it impossible to identify which system they belong to.
  • Broken connectivity. Fittings (elbows, tees, reducers) that aren't properly connected to their adjacent segments in the IFC graph.
  • Lost property sets. Custom shared parameters in Revit that don't map to standard IFC property sets and get silently dropped.
  • Simplified geometry. Complex MEP components (air handling units, heat exchangers) reduced to bounding boxes.

The Property Set Problem

IFC defines standard property sets for common attributes — things like nominal diameter, shape, and working pressure for duct segments. Great — except every firm uses additional custom properties that don't fit into these predefined sets.

You can define custom property sets, and you should. But there's no universal agreement on naming conventions, units, or value types. One firm's "InsulationThickness" is another firm's "Insul_Thk_mm" is another's "DämmstärkeInMillimeter."

buildingSMART's bSDD (buildingSMART Data Dictionary) is meant to solve this with a shared classification system, but adoption is still low.

What buildingSMART Is Doing About It

The organization behind IFC isn't standing still. Several initiatives are worth watching:

IFC4.3 — Infrastructure Extension

IFC4.3 extends the schema to cover roads, bridges, railways, ports, and waterways. This is a big deal for infrastructure projects that previously had no open data standard.

IDS — Information Delivery Specification

IDS is a machine-readable way to define what information an IFC model should contain. Instead of a 50-page BIM Execution Plan that nobody reads, you define an IDS file that automated tools can validate against. "Every duct segment must have a nominal diameter specified in millimeters" — expressed as structured data, not prose.

This is potentially transformative. If adopted widely, IDS turns model quality checking from a manual process into an automated one.

IFC5 — The Rewrite

IFC5 is in early development and aims to address fundamental schema issues. The biggest change: moving from the legacy STEP serialization to a modern format (likely JSON-LD or a graph database format) that's easier for web applications to consume.

For those of us building web tools around BIM data, IFC5 can't come soon enough.

What the Industry Can Do Right Now

Invest in Open-Source Tools

The open BIM ecosystem has some excellent tools that deserve more attention and contribution:

  • IfcOpenShell — The best open-source IFC toolkit. If you've ever programmatically worked with an IFC file, you've probably used this.
  • BlenderBIM — A full BIM authoring environment built on Blender. Open source, community-driven, and surprisingly capable.
  • xBIM — A .NET library for IFC, popular in the Revit add-in world.

Build IFC-Native Tools

Instead of building tools that import from proprietary formats and export to IFC as an afterthought, build tools that are IFC-native — where IFC is the primary data model, not a translation target.

This is what I'm exploring with Mepbau: can a web-based HVAC calculation tool produce IFC output natively, so the results feed directly into the BIM coordination workflow?

Push for IDS Adoption

If you work with BIM managers or project coordinators, advocate for IDS-based model quality requirements. The tooling is ready — Solibri, SimpleBIM, and IfcOpenShell all support IDS validation.

My Prediction

IFC won't replace proprietary formats for authoring. Architects will keep designing in ArchiCAD, structural engineers in Tekla, MEP engineers in Revit. These tools are deeply optimized for their domains, and IFC isn't meant to replicate that.

What IFC will replace is the exchange layer. Within 10 years, I believe:

  1. IFC + cloud APIs will replace file-based model exchange. Instead of emailing .ifc files, teams will query a shared model server.
  2. IDS will replace PDF-based BIM execution plans. Model requirements will be machine-readable and automatically validated.
  3. IFC-native web tools will emerge for specific workflows (model checking, quantity takeoff, energy simulation, HVAC sizing) that don't need full authoring capability.
  4. Property standardization via bSDD will reach critical mass in specific domains (MEP being one of them), solving the custom property chaos.

The proprietary format cold war won't end with a treaty. It'll end because the exchange infrastructure becomes so good that it doesn't matter what format you author in — the data flows regardless.

We're not there yet. But every open-source contribution, every IDS specification published, and every IFC-native tool built moves the needle.

Working on IFC tooling or open BIM development? I'm always interested in what others are building. Drop me a line at hello@laborsam.com.