Why the industry needs IFC5
For years the core of IFC has been the STEP file format, and with it a dependency on exchanging files. That model is now holding the industry back. Newer ways of working ask for something different: multidisciplinary collaboration in the cloud, with control over access rights and workflow stages; common data environments (CDE) becoming the norm; and the streaming of point clouds and other heavy data.
All of these need a restructured standard, one that lets content be edited in a distributed way rather than locked inside files.
The roadmap, drawn up as a broad committee effort by members deep in the development of earlier versions, names a few more problems with the file-based approach:
- Developing and standardising IFC has been too heavy and too slow
- Support for IFC features has fragmented across software and stayed hard to see. Only a fraction of the tools that claim IFC4 support actually handle NURBS data transfer, for example
- Responding to real industry needs has not been agile or fast enough
What modular IFC5 changes
IFC5 answers those problems by breaking the standard into modules. The practical gains:
- Faster exchange, because software moves content through APIs instead of shipping whole model files
- Faster support for new IFC versions and features, built on a stable, standardised base
- New modules and extensions that can be adopted immediately
- Better interoperability between IFC modules, such as the extensions for different design disciplines
- More transparent certification, through a scorecard that shows what each tool actually supports
- IDS and bsDD building on the same standardised base, supporting a single, coherent information model
Before, the fragmented adoption
For a long time IFC development was guided by the Model View Definition (MVD). Each MVD was written to serve one data-exchange use case, for example what passes from the architect to the structural engineer. Writing a definition and getting software certified against it could take around five years. buildingSMART's model was that tools would develop once a case was defined and they wanted to certify against it.
In practice the result was patchy. Many vendors never certified at all and adopted the concept themselves, partly and inconsistently. The IFC 4.x definition grew far larger than its predecessors and carried some 300 documented exceptions. MVD versions were developed in parallel by separate working groups, which led to overlaps and conflicts.
After, back to basics
IFC5 standardises the IFC 4.3 features so they line up between IFC and bsDD, and it brings in the Information Delivery Specification (IDS) along with a new way to certify software.
That new certification is scorecard-based. It runs alongside the older method as a more scalable approach, comparing a tool against the whole standard and showing its support area by area. End users can finally see clearly where tools differ in their IFC feature support.
buildingSMART wants more of the industry to take part. Clients can define their information requirements as IDS, and manufacturers can publish their content libraries in bsDD. The base of the standard stays constant while case-specific needs are met more flexibly, and software vendors stay responsible for implementing IFC, IDS and bsDD support in their products.
All of these can work dynamically rather than as fixed files. IFC language versions and manufacturers' product data can be served like a live library. Even IFC support for products outside the standardised core can be developed more quickly, for instance by industry interest groups working with buildingSMART. The Finnish RAVA content, which is not part of any official MVD, is a good candidate to deliver as an IDS definition.
IFC 4.3.2 and the path to IFC5
The first model requirement in Finland's new construction law will be IFC 4.3.2, which will be the last IFC version based on a file-based definition. Its biggest practical advance over 4.0 is support for infrastructure model parts, such as alignments, bridges and piers, and for broader digital-twin content. The 4.3.2 requirement also brings better transfer of building-material properties, support that moved forward in version 4.
So 4.3.2 is the last of its kind, but it is the benefits of the next generation that pull the industry towards more advanced collaboration.
The Finnish model decree is written as "IFC 4.3.2 or newer", which both allows and encourages early adoption of newer versions. The same principle sits behind the earlier National Archives decision, which accepted IFC as an archival format for construction BIM models. The rest of the Nordics are moving the same way.
What this means for Archicad users
Graphisoft is implementing 4.3.2 support in Archicad 29. That makes it the first Archicad version to meet the model decree of the construction law taking effect on 1 January 2026. The IDS support already added in Archicad 28 is another marker of the same direction of travel, and its scope will keep growing.
The IFC5 style of CDE collaboration is already everyday work for Archicad users through Teamwork. You can already run multidisciplinary projects alongside MEP designers, and Archicad's SAF link to structural analysis tools works on the same principles, for now still file-based.
What remains is bsDD support, which is still on the way.
Staying ready for what comes next
IFC5 is still taking shape, but its direction is clear: open standards, live collaboration in the cloud and information that moves without being trapped in files. The IFC 4.3.2 requirement arriving with Finland's construction law is the near-term step, and the move to Archicad 29 is how Archicad users meet it.
If you want to get your team and your templates ready, or to understand what openBIM means for your projects, talk to us.
