IFC is maintained by buildingSMART International and standardized as ISO 16739. It exists to solve one problem: every BIM authoring tool stores models in its own proprietary format, but the people who need model data — engineers on other teams, cost consultants, facility managers, analysts — rarely use the tool it was authored in.
How it works
An IFC file describes a building as a structured set of typed entities. Walls are IfcWall, floors are IfcSlab, levels are IfcBuildingStorey, and each element carries property sets: dimensions, materials, classifications, and any custom parameters the author exported. The schema also captures the spatial hierarchy — site, building, storey, space — so downstream tools understand not just what an element is, but where it lives in the project.
Frame glossary
One neutral file, many consumers
Common schema versions you will meet in practice are IFC2x3 (still the most widely exchanged), IFC4, and the newer IFC4.3, which extends the standard to infrastructure like roads and rail. Export quality varies by authoring tool and by the export settings the author chose — an IFC is only as complete as the mapping that produced it.
Why it matters for BIM analytics
For analytics, IFC’s value is that its property data is inspectable without the authoring tool. Element types, storey assignments, and property sets can be extracted and turned into tables — which is exactly how Frame processes IFC uploads: models are converted into Power BI and Excel datasets, with IfcType and IfcBuildingStorey used to build the element hierarchy. If you can get a clean IFC out of your authoring tool, you can get a dashboard out of it.
IFC is also the neutral ground of a federated model: when architecture, structure, and MEP come from different vendors, IFC is usually the format they meet in.