COBie vs IFC: A Practical Guide to Handover Data (and Where Classification Fits)

"COBie vs IFC" gets searched a lot, and the framing itself is a little misleading. They're not two competing ways to do the same job. IFC is the open schema that carries a building's geometry and data. COBie is a specific, purpose-built extract of that same IFC data, filtered down to exactly what a facility manager needs at handover. Once you see it that way, most of the confusion around both formats, and where classification systems like Uniclass fit in, stops being confusing.

What COBie actually is

COBie, Construction Operations Building Information Exchange, is a structured data format for capturing information about a facility's maintainable assets, equipment, spaces, and systems, for handover to the people who will run the building afterward. It's delivered as a spreadsheet (SpreadsheetML, effectively Excel), and under the current v3 specification, also available as JSON or as an IFC file. Its worksheets, Facility, Level, Space, Zone, Type, Component, System, Job, Document, Attribute, and PickList, link asset types to installed components, the spaces they sit in, and the maintenance tasks tied to them.

It was originally published by the U.S. Army Corps of Engineers in 2007, with support from NASA and the White House Office of Science and Technology Policy, and has been maintained by the National Institute of Building Sciences since 2013 under a Creative Commons license. In the UK, government BIM policy adopted COBie in 2011, and BS EN ISO 19650-2 (2019) specifies it as the format for non-geometric data exchange.

IFC vs COBie: different jobs, not rival formats

IFC, Industry Foundation Classes, is an open, vendor neutral, ISO standardized schema (ISO 16739-1:2024) maintained by buildingSMART, covering physical elements, materials, properties, relationships, and even abstract data like cost or schedule information. It underpins the entire openBIM data exchange ecosystem, alongside IDS and BCF, across design, coordination, construction, and facility management.

COBie, by contrast, is formally a Model View Definition of IFC, meaning it's a defined, buildingSMART sanctioned "view" into IFC data, scoped narrowly to the specific asset and FM information an owner needs. It is not a competing modeling format and was never meant to hold the same range of information IFC can carry. Confusing the two as competitors is the single most common source of "why doesn't my COBie export have everything my model has" frustration.

Where classification systems actually fit

Uniclass, OmniClass, and Uniformat are content vocabularies, not file formats. They supply hierarchical codes that populate specific fields inside IFC and COBie, not a third exchange format competing with either. In IFC, classification codes are carried by the IfcClassificationReference entity. In COBie, they populate dedicated .Category fields per table, for instance Type.Category referencing OmniClass Table 23 or Uniclass Table Pr, and System.Category referencing OmniClass Table 21 or Uniclass Table EF, each pointing to an approved PickList. buildingSMART's Data Dictionary, bSDD, which we covered in our bSDD explainer, adds a further layer, standardizing the property and term definitions that reduce ambiguity across classification and naming.

The handover mistakes that keep recurring

• Incomplete COBie exports from IFC. COBie parameters mapped correctly inside an authoring tool don't always survive IFC export, and IFC generated straight out of common authoring tools is frequently reported as poor quality, requiring manual audit and correction before it's usable.
• Missing or wrong IFC classification. Elements without the correct IFC class can be wrongly excluded, or wrongly included, once that data reaches a downstream CAFM or facilities management system.
• Legacy MVD tooling. Older COBie export routes built on IFC2x3 based Model View Definitions are documented as unreliable; moving to IFC4 based COBie MVDs is the more consistent path.
• Spreadsheet process failures. Version control chaos from multiple people editing separate copies, broken references from incorrect filtering, and data integrity loss from copy pasting between sheets, all well outside anything COBie the specification actually controls.
• Treating COBie as a live collection tool. The deepest root cause reported across sources: teams try to maintain COBie continuously through design and construction instead of treating it as a validated output produced once, correctly, at the end of the process.

Frequently asked questions