BIM Problem IFC Errors: BIM Reality Check Series Part 2

BIM Reality Check Series · Part 2 of 5

IFC Export Errors Are Not Just File Problems: The Truth About BIM Interoperability

By Structural Integrity Editorial Team  ·  Published May 2026  ·  Last Updated May 2026  ·  14 min read

Quick Answer

IFC (Industry Foundation Classes) is the international open standard for exchanging BIM data between software platforms. But "standard" does not mean "automatic." Every IFC export from Revit, Archicad, or any other authoring tool requires configuration, validation, and often manual correction before it reliably works in another platform. Geometry loss, coordinate drift, missing properties, and software-specific interpretation differences are documented, repeating problems — not edge cases.

New to BIM? Start Here

What is IFC — and why does it matter even if you are not an architect?

Think of IFC as the PDF of the construction world. Just as PDF lets you share a document that looks the same whether you open it in Adobe Reader, Chrome, or a printer — IFC is supposed to let you share a building model that looks the same (and carries the same data) whether you open it in Revit, Archicad, or a facility management system. The difference: PDF actually works. IFC works in theory, and mostly in practice — but with enough documented exceptions that every practitioner has an IFC failure story. For investors and owners, this matters because IFC is the mechanism through which BIM data is supposed to survive software changes, contractor transitions, and operational handovers. When IFC fails, data does not transfer — and that has cost implications.

In 2025, a structural engineer working on a hospital expansion project exported her Revit model to IFC to share with the MEP contractor. The file opened in the contractor's Navisworks without errors — but 23 doors were missing entirely, and a section of structural steel had shifted 400 meters from its correct position. Neither error was visible in Revit. Both required hours of manual investigation to identify and correct. The project deadline did not move.

This is not a horror story. It is a routine Tuesday in firms that regularly work across software platforms. IFC interoperability problems are so common that Autodesk maintains a dedicated IFC manual with version-specific update notes, and GitHub issue trackers for Revit IFC plugins contain hundreds of open bugs filed by practitioners. The industry calls this "interoperability." Practitioners call it "the IFC problem."

This article explains what IFC actually is, why it was created, where it reliably works, where it consistently fails — and what those failures cost in real projects.

What Is IFC? A Complete Explanation for Non-Specialists

The Problem IFC Was Designed to Solve

Before IFC existed, sharing a building model between different software platforms meant one of three things: you used the same software as everyone else (expensive and contractually complicated), you exported to a "neutral" CAD format like DXF or DWG and lost most of the intelligent data in the process, or you re-modeled the relevant parts yourself from scratch.

IFC was developed by buildingSMART International — a non-profit standards organization — to create a truly neutral, software-independent format for BIM data. The first version was released in 1997. The current widely-used versions are IFC2x3 (released 2006) and IFC4 (released 2013), with IFC4.3 the most recent standard as of 2026.

The goal was ambitious: an open format that any BIM software could read and write, preserving not just geometry but all the data attached to building elements — materials, fire ratings, structural properties, energy parameters, cost codes, maintenance schedules. A wall in Revit should export as a wall in IFC with all its properties intact, and import as a wall in Archicad with all those properties still readable.

How IFC Stores Data: The Technical Layer (Simplified)

IFC files use a text-based format called STEP (Standard for the Exchange of Product model data). If you open an IFC file in a text editor, you will see lines like #123= IFCWALL('3Fw...',#12,'Wall:Basic Wall',$,'Basic Wall',...) — each line defining a building element with its unique ID, type, name, and relationships to other elements.

This structure means IFC is not just a 3D mesh export like OBJ or STL. It carries a complete object hierarchy: a building contains floors, floors contain spaces, spaces contain walls, walls contain materials, materials have properties, properties have units. The entire data graph — not just the shapes — is supposed to travel with the file.

For investors and owners: this is the architecture that is supposed to make BIM data valuable beyond the design phase. If IFC works correctly, a hospital owner receives a model where every room, every piece of equipment, every system has its data attached — ready to import into a facility management system that can use it for maintenance scheduling, energy monitoring, or capital planning. When IFC does not work correctly, they receive a model-shaped 3D file with varying degrees of missing or incorrect information.

The OpenBIM Vision: Why It Matters Commercially

buildingSMART's "OpenBIM" initiative positions IFC as the foundation for a software-agnostic construction industry — one where owners are not locked into a single vendor's ecosystem, where data flows freely between best-of-breed tools, and where the building's digital twin survives platform changes across its 50-year operational life.

This vision is commercially significant. It is the argument that public sector clients in Europe, Scandinavia, and increasingly Asia use to mandate IFC deliverables on publicly funded construction projects. It is the argument that facility operators use to require IFC handover in contracts. And it is the argument that positions the entire OpenBIM ecosystem as an alternative to Autodesk's closed-format dominance.

The problem — as the rest of this article documents — is that the vision and the current reality are separated by a significant, measurable gap.

Where IFC Consistently Fails: Documented Problems

1. Geometry Loss and Misinterpretation

The most visible IFC failure is geometry that does not survive the export/import cycle. Custom Revit families — parametric components that do not map cleanly to standard IFC object types — frequently export incorrectly, appear as generic solid shapes without type data, or disappear entirely.

A technical post by BIM Heroes specifically analyzed "Why Your IFC Export Fails" and identified custom family disappearance as one of the most common Revit-to-IFC failures, alongside geometry missing from Navisworks imports and object glitches that appear across multiple projects and machines. The Autodesk Community forums contain multiple threads — filed by different users, on different versions of Revit, in different years — describing identical export failures.

A GitHub issue filed against the Autodesk Revit IFC plugin in 2024 (issue #821) documented that Revit 2025 IFC 4x3 export was failing to export certain door types. Autodesk's official response: the fix would be available in Revit 2026. For practitioners delivering IFC files on 2025 projects, "upgrade to next year's software" is not a solution.

2. Coordinate Drift: When Your Building Moves Kilometers

One of the most disorienting IFC failures involves coordinate systems. A model that is correctly positioned in Autodesk Construction Cloud — or in Revit's internal coordinate system — can export to IFC and appear "kilometers away" from its intended position when opened in another application.

This is not a rare edge case. A detailed technical analysis by CoulterBIM documented coordinate drift specifically occurring when ACC-aligned models are exported to IFC and opened in applications like BonsaiBIM or Solibri. The root cause is that Revit uses an internal "survey point" and "project base point" system that does not map predictably to the coordinate references used by other IFC-compliant tools.

For multi-disciplinary projects — where an architectural model, structural model, and MEP model need to be federated in a coordination platform — coordinate drift means the models do not align. A structural column is not where the architectural opening is. A pipe runs through a wall that no longer exists in the coordination view. Clash detection cannot run correctly. Every federated review requires a coordinate correction step before it can begin.

3. Property Data Loss

IFC's value proposition is that properties — material specifications, fire ratings, energy parameters, cost codes — travel with the geometry. In practice, properties are one of the most common casualties of IFC export.

Revit stores custom properties in its own parameter system. Mapping Revit parameters to IFC property sets requires explicit configuration in the IFC export settings — a process that Autodesk's own IFC manual covers in detailed sections on "User Defined Property Sets" and "IFC Export Category Mapping." If this mapping is not set up correctly, properties that exist in the Revit model simply do not appear in the IFC output.

The Bentley Communities forum thread "IFC full of errors" — describing failed collaboration between a Revit team and teams using Bentley tools — cited wrong interpretation of properties and geometry loss as the specific failures making the workflow "practically impossible." This was not a Revit problem or a Bentley problem in isolation: it was an interoperability problem that neither vendor's support team resolved.

4. Version Fragmentation: IFC2x3 vs IFC4 vs IFC4.3

IFC has multiple versions, and different software applications implement different versions with different levels of completeness. IFC2x3 is the most widely supported version, but it dates from 2006 and lacks schema elements needed for modern BIM workflows. IFC4 added significant improvements but has inconsistent implementation across tools. IFC4.3 is the current standard but has limited software support as of 2026.

This means that even when everyone in a project claims to be "using IFC," they may be using incompatible versions with incompatible feature sets. A property set that exists in IFC4 may not have an equivalent in IFC2x3. A geometry representation that works in one version may fail in another.

IFC Reality: What Works vs. What Breaks — Platform by Platform

Software Pair	Geometry	Properties	Coordinates	Reliability
Revit → Navisworks	Mostly preserved	Requires mapping config	Drift risk if survey point not set	Moderate
Revit → Archicad	Custom families often lost	Significant loss common	Frequent drift issues	Low
Revit → Solibri	Generally good	Depends on export config	Requires explicit georef setup	Moderate
Revit → Bentley	Wall geometry loss reported	Wrong interpretation common	Misalignment frequent	Low
Archicad → Revit	Partial preservation	Manual adjustment needed	Manual correction required	Low–Moderate
Any → IFC Viewer only	Usually adequate	Readable (not editable)	May appear offset	Good

Note: Reliability ratings reflect general practitioner experience reported in industry forums and technical documentation as of 2026. Results vary based on model complexity, export configuration, and IFC version used. Always validate IFC outputs before relying on them for coordination or handover.

The Autodesk Paradox: They Sell the Problem and the Workaround

The most revealing evidence about the state of IFC interoperability comes not from critics but from Autodesk's own documentation.

Autodesk operates a dedicated IFC manual at autodesk.ifc-manual.com. The existence of this manual — with sections covering IFC Export Category Mapping, Link IFC workflow, User Defined Properties, and version-specific update notes for 2025 and 2026 — is itself diagnostic. If IFC export worked reliably out of the box, a dedicated manual with annual update cycles would not be necessary.

The official Autodesk Revit IFC Manual PDF (hosted on damassets.autodesk.net) contains a passage that is remarkable in its candor: the "design transfer workflow" — meaning the process of taking a model created in a different software and continuing design work in Revit — is described as "more difficult," requiring "manual adjustments to handle software differences." This is Autodesk, in its own documentation, telling users that cross-software IFC workflows require manual intervention.

Meanwhile, Autodesk's marketing page for BIM Interoperability describes IFC as a "neutral exchange mechanism" — language that implies smooth, automatic data transfer. Both documents are accurate. Together, they illustrate the gap between what IFC promises and what IFC delivers.

What IFC Failures Cost: A Business and Investor Perspective

For investors and project owners evaluating BIM adoption, IFC interoperability failures translate directly into cost and schedule risk in ways that are rarely quantified upfront.

Failure Type	Practical Impact	Typical Cost Driver
Geometry loss on export	Contractor builds from incomplete model; site discovery required	RFIs, change orders, site rework
Coordinate drift	Federated model unusable; clash detection cannot run	Coordination delay, manual re-alignment labor
Property data loss	FM system handover fails; operations team re-enters data manually	O&M data re-entry cost, handover delay
Version mismatch	Deliverable rejected by client; re-export required	Rework time, potential contract disputes
MEP export timeout	2–5 hours per export on large models; workflow bottleneck	Staff time cost, coordination cycle delays

The MEP export timeline figure — 2 to 5 hours per export for large models — comes from user reports in the Autodesk Community forums. On a project with weekly coordination cycles, that is 2 to 5 hours of blocked workflow per week, per discipline, before anyone has even opened the file to check for errors.

For investors and owners evaluating BIM mandates or IFC handover requirements in contracts, the key question is not "does the project team use IFC?" but rather "what is the validation protocol, who owns the validation cost, and what are the contractual consequences of delivering an IFC file that fails in the client's systems?" These questions are rarely asked before contract signing and frequently become disputes after project completion.

IFC Export Validation Checklist: What to Check Before You Send Any File

Every IFC file should be validated against this checklist before it is treated as a deliverable. If your workflow does not include these steps, you are not delivering IFC — you are delivering an IFC attempt.

IFC Pre-Delivery Validation Checklist

Geometry Checks

Open in a second application — Always open the IFC export in a different application from the one that created it (e.g., open Revit exports in Solibri or BonsaiBIM)

Count elements — Compare element count in IFC vs. source model; significant discrepancies indicate geometry loss

Visual spot-check custom families — Manually verify that non-standard components (custom doors, complex curtain wall panels, specialty equipment) export correctly

Coordinate Checks

Confirm project base point before export — Set and lock the project base point and survey point in Revit before exporting; document the coordinate offset used

Federate test before delivery — Combine with at least one other discipline model in the receiving platform to verify alignment before submitting

Property Checks

Check property set mapping configuration — Verify that project-specific parameters are mapped to IFC property sets in the export settings, not left at defaults

Spot-check key properties on 10+ elements — Open the IFC in Solibri or BIMcollab and manually verify that fire ratings, material specs, and space names are present and correct

Version and Compliance

Confirm required IFC version with recipient — Before exporting, confirm whether IFC2x3, IFC4, or IFC4.3 is expected; do not assume

Run a schema validation tool — Use a free tool such as IfcOpenShell or the buildingSMART validation service to check the file against the IFC schema before delivery

Time estimate: A thorough IFC validation for a medium-complexity model takes 2–4 hours. This should be budgeted into every coordination cycle — it is not optional if the file is being used for coordination, cost, or handover purposes.

What Actually Works Well in IFC Workflows Today

Acknowledging the failures is not a case for abandoning IFC. It is a case for calibrating expectations and investing validation effort where it matters. There are IFC use cases where the standard performs reliably and delivers genuine value.

IFC for viewing and coordination review works well. Reading an IFC file in a viewer like BIMvision, xBIM, or Autodesk's IFC viewer is generally reliable for geometry. Stakeholders who need to understand the spatial design — clients, planning authorities, facility operators — can use IFC viewers effectively without needing to own BIM authoring software.

Clash detection in Solibri or BIMcollab works reasonably well when coordinate issues are resolved and geometry is complete. These tools are purpose-built for IFC-based coordination and have mature parsers that handle Revit and Archicad exports more reliably than general-purpose tools.

COBie exports for facility management data — a structured IFC-based format for asset data handover — work well for assets that have been consistently modeled with COBie parameters. This requires discipline during model authoring but produces reliable facility management datasets when done correctly.

Nordic and UK public sector projects that mandate IFC under government BIM frameworks have demonstrated that IFC-based workflows can function at scale — but these projects invest significantly in upfront data standards, BIM Execution Plans, and validation protocols that most commercial projects skip.

Frequently Asked Questions

Is IFC the same as an open standard for all BIM software?

IFC is an open schema — the specification is publicly available and any software can implement it. But each software vendor implements the IFC schema differently, with different levels of completeness and different interpretations of edge cases. "IFC-certified" software has passed basic compliance tests, but certification does not guarantee round-trip fidelity or property preservation across all use cases.

Why does Revit IFC export fail so often?

Revit's internal data model and IFC's schema are structured differently. Revit organizes data around its own family-and-parameter system; IFC organizes data around a standardized object hierarchy. Translating between them requires a mapping layer that Autodesk has implemented over many versions — but incompletely. Custom Revit families, shared coordinates, and complex assemblies are the most common failure points because they diverge most from IFC's standard object types.

Should investors require IFC delivery in contracts?

Yes — with validation requirements attached. An IFC deliverable clause without a validation protocol and acceptance criteria is largely unenforceable. Contracts should specify: IFC version required, the validation tool or protocol to be used, acceptance criteria (e.g., element count tolerance, required property sets), and a rejection and remedy process for non-compliant files.

Will IFC problems be solved by the next version of the standard?

IFC4.3 addresses some schema gaps, particularly for infrastructure projects. But schema improvements alone do not solve the implementation problem — each software vendor still needs to update their IFC exporter/importer to the new version, and those updates take years to reach stable production status. IFC2x3 was published in 2006 and is still the most widely used version in 2026. Schema advancement and practical interoperability move at very different speeds.

Key Takeaways

• IFC is a genuine open standard with a sound architecture — but software implementations are incomplete and inconsistent across vendors
• Geometry loss, coordinate drift, and property data loss are documented, recurring problems — not edge cases
• Every IFC file should be validated in a second application before being used for coordination, cost, or FM handover
• Autodesk's own documentation acknowledges that cross-software IFC workflows require manual adjustments
• For investors: IFC clauses in contracts need validation protocols and acceptance criteria — not just a file format requirement
• IFC works best for viewing, coordination review, and COBie-based FM handover when supported by proper configuration and validation

Next in the BIM Reality Check Series

Part 3: Revit, Rhino, and Grasshopper Workflow Problems — Where BIM Interoperability Breaks

Rhino handles complex geometry that Revit cannot. Revit handles documentation that Rhino cannot. Connecting them requires a bridge — and that bridge creates its own friction, performance problems, and data loss. Part 3 examines what happens in the middle.

About This Series

The BIM Reality Check series is produced by the Editorial Team at Structural Integrity, drawing on practitioner reports, technical documentation, academic research, and industry forums to examine where BIM workflows succeed and where they structurally fail.

All claims in this series are sourced from verifiable references. Where data is unavailable or uncertain, it is marked accordingly. This series does not constitute engineering or legal advice.