IFC 4.3 and IFC5: What AEC Teams Should Prepare For

The Industry Foundation Classes (IFC) schema is the backbone of openBIM exchange, and it is changing on two fronts at once. IFC 4.3 has been published as an ISO standard, extending the schema well beyond buildings into infrastructure. Meanwhile, buildingSMART International is developing IFC5, a more fundamental rethink of how IFC data is structured and exchanged. For AEC teams and for anyone building IFC viewers or pipelines, the practical question is what to act on now and what to watch. This article separates the two.

Where IFC stands today

Most real-world IFC exchange still happens with IFC2x3 and IFC4. IFC2x3 remains common because many authoring tools and downstream checkers supported it for years, and project requirements often still name it. IFC4 adds better geometry options, richer property handling, and clearer model view definitions such as the Reference View and Design Transfer View.

IFC 4.3 is the latest published version of the schema. buildingSMART finalised it and it was published by ISO as ISO 16739-1:2024. Its headline change is infrastructure coverage.

What IFC 4.3 adds

• Alignment and linear referencing, so elements can be positioned along a road or rail alignment rather than only in a local Cartesian system
• Domain extensions for infrastructure, covering roads, railways, bridges, and ports and waterways
• Improved geotechnical and earthworks concepts, useful for civil and ground engineering data
• Refinements to existing building concepts, carried forward from IFC4 so building workflows are not left behind

For building-only projects, IFC 4.3 is largely a superset of IFC4. The practical impact depends on whether your authoring tools export it and whether your downstream tools can read it.

What IFC5 is, and what it is not yet

IFC5 is in active development by buildingSMART International. It is not a released standard, and its design is still changing. Anyone making firm product commitments against specific IFC5 structures today is taking on risk.

That said, buildingSMART's public IFC5 development work explores several directions worth understanding:

• A modern serialisation format, with JSON-based representations being explored instead of relying solely on the STEP physical file format that IFC has used for decades
• A more modular, composable data model, where information about an element can be contributed in layers by different parties rather than packed into one monolithic file
• Easier consumption by web and software developers, lowering the barrier for tools that today need specialised IFC parsers
• Better support for incremental exchange, so changes can be shared without re-exporting an entire model

These are directions, not guarantees. Details may change significantly before any official release, and adoption by authoring tools will take time after that.

What AEC teams should do now

You do not need to wait for IFC5 to improve your openBIM delivery. Most of the value comes from getting today's exchange right.

Be explicit about IFC versions in requirements

Exchange requirements often say "IFC" without specifying a version or model view. That leaves each party to pick their own export settings, and the results vary. Name the schema version and model view definition for each exchange, and test a sample export early in the project.

Define information requirements in machine-readable form

buildingSMART's Information Delivery Specification (IDS) lets you express what properties, classifications, and values elements must carry in a form software can check. Even if you start with a small set of rules, IDS moves requirements out of PDFs and into something that can be validated automatically. That work carries forward regardless of which IFC version you exchange.

Validate exports, do not assume them

The most common IFC problems are not schema problems. They are export problems: missing property sets, elements on the wrong storey, lost classifications, or geometry that did not survive conversion. Open every significant export and check it. A lightweight way to do this is our free IFC viewer, which opens IFC2x3 and IFC4 files in the browser so you can inspect spatial structure and properties without installing software.

Plan for infrastructure data if you work across domains

If your projects include roads, rail, or bridges alongside buildings, IFC 4.3 is the version that can carry that information in a standard way. Start conversations with authoring tool vendors and downstream consumers about their IFC 4.3 support, and pilot it on a contained part of a project before relying on it.

What IFC viewer and pipeline builders should prepare for

If you build or maintain software that reads IFC, the priorities are slightly different.

Separate parsing from your application model

Tools that bind their user interface directly to STEP entity structures will find any schema change painful. A cleaner approach is to parse IFC into an internal model of spaces, elements, properties, and relationships that your viewer uses. Supporting IFC 4.3 entities, or later an IFC5 serialisation, then becomes a matter of adding a new reader rather than rewriting the application.

Handle schema versions explicitly

Detect the schema declared in each file and route it accordingly. Report unsupported versions clearly instead of failing silently or rendering partial geometry without warning.

Treat georeferencing and alignment as first-class

IFC 4.3's alignment concepts and improved map conversion handling matter for any viewer that needs to place models in real-world context. Test with georeferenced files, not only with models at the origin.

Watch IFC5 without building on it prematurely

Follow buildingSMART's public development work, experiment with sample data in a sandbox, and give feedback where you can. Avoid shipping production features that depend on draft structures.

A readiness checklist

• Exchange requirements name the IFC version and model view for each deliverable
• A sample export has been opened and checked for structure, properties, and classifications
• Information requirements are captured, at least partially, in IDS
• Downstream tools have confirmed which IFC versions they read
• Infrastructure scopes have a plan for IFC 4.3 support
• Viewer or pipeline code isolates parsing from application logic
• Someone on the team is tracking buildingSMART's IFC5 development updates

How we approach this at BimEx

When we build a custom IFC viewer, we design the data layer so the viewer does not depend on a single schema version. That keeps today's IFC2x3 and IFC4 support robust while leaving room for IFC 4.3 entities and whatever IFC5 eventually looks like. If you are deciding how far to invest in openBIM tooling right now, contact us and we can talk through the trade-offs for your pipeline.

Key takeaways

• IFC 4.3 is published as ISO 16739-1:2024 and mainly extends IFC into infrastructure: alignment, roads, rail, bridges, and ports.
• IFC5 is still in development at buildingSMART International; treat its structures as drafts, not commitments.
• Most openBIM value today comes from specifying versions clearly, validating exports, and using IDS for information requirements.
• Viewer builders should decouple parsing from application logic so new schema versions can be added without a rewrite.