IFC, COBie and ISO 19650: BIM Deliverables Explained

By Categories: Uncategorized7.1 min read
M:\USERs\An.Nguyen\3501

TL;DR: 3 things to know

  • 01

    IFC is an exchange format, not a modeling format. Imported IFC objects often behave as “dead objects” that cannot be edited the way native elements can.

  • 02

    COBie packages the non-graphical asset data a facility team actually needs, such as equipment, spaces and attributes, for handover into a CMMS/CAFM system.

  • 03

    ISO 19650 does not mandate a specific software or format. It standardizes how BIM information is managed and exchanged across a project’s lifecycle.

IFC, COBie, and ISO 19650 come up in almost every BIM deliverables conversation, but the three terms get mixed together more often than they should. IFC is a file format. COBie is a data schema built for facility handover. ISO 19650 is a management standard, not a file format at all. Understanding what each one actually does, and doesn’t do, makes it much easier to specify what you actually need from a Scan-to-BIM deliverable.

Three separate panels comparing IFC, COBie and ISO 19650: IFC as a file exchanged between software, COBie as asset data feeding a facility dashboard, ISO 19650 as an information management workflow
IFC, COBie and ISO 19650 each do a different job in a BIM deliverable.
IFCCOBieISO 19650
What it isOpen, vendor-neutral exchange file format (buildingSMART)A data schema for non-graphical asset informationAn international information-management standard
What it is forMoving models between software; coordination and clash detectionHanding structured asset data to a CMMS/CAFM system at FM handoverDefining how BIM information is produced, shared, and archived across a project
What it is notNot a modeling format; imported objects often lose editabilityNot a 3D modelNot a file format or software; not something a single deliverable can be certified for
Delivered asAn .ifc export alongside the native BIM fileA structured spreadsheet export, on requestConsistent naming, documented QC, and a CDE-compatible workflow

What Is IFC, and Why It Matters for BIM Delivery

IFC (Industry Foundation Classes) is an open, vendor-neutral file format designed so BIM models can move between different software platforms such as Revit, Archicad, Allplan and Vectorworks, without everyone needing to use the same tool. It is maintained by buildingSMART International and is the closest thing the industry has to a universal BIM exchange format.

That interoperability is genuinely useful for specific tasks: clash detection between disciplines, model review in a lightweight viewer, or handing off geometry and data to a platform that doesn’t need to edit it. IFC is an exchange format, and it does that job well.

IFC vs. Native Files: What You Can and Cannot Do

Where IFC runs into trouble is when it’s treated as a modeling format instead of an exchange format. A common but costly assumption is that a model can simply be exported to IFC, imported into a different BIM platform, and edited there as if it had been modeled natively.

A real example: the “dead object” problem

Most standard IFC elements such as walls and columns import cleanly and stay editable. But many other objects don’t survive the round-trip as intelligent, parametric elements. A window imported as IFC into a different platform can behave as a “dead object”: to change it, you often have to redraw it from scratch, and the smart wall-to-window relationship is lost in the process. Teams that discover this mid-project sometimes end up remodeling the entire building natively, after already paying for an IFC-based deliverable that could not actually be edited.

Isometric BIM diagram: two windows stay editable parametric elements with grip handles while one window imported via IFC becomes a red dead object detached from the wall
Native walls and windows stay editable; an IFC-imported window can lose its link to the wall and become a “dead object.”

The practical takeaway: IFC is well suited for interoperability tasks like coordination and clash detection. If your team needs to keep editing the model, whether for renovation planning, ongoing design changes or permit revisions, a native file (Revit, Archicad, Allplan, or Vectorworks) is what actually stays editable. IFC should be requested alongside the native file, not instead of it. Our Point Cloud to Revit workflow guide walks through what a native, LOD-defined deliverable looks like in practice.

COBie: Structured Data for Facility Handover

COBie (Construction Operations Building Information Exchange) is a different kind of format entirely. It is not primarily about geometry. COBie packages the non-graphical asset data a facility management team actually needs to operate a building: equipment lists, spaces, manufacturer and model information, and other attributes, structured so they can be imported directly into a CMMS or CAFM platform.

A geometry-only model, even a well-modeled native file, doesn’t automatically give a facility team anything they can query. Without a structured export like COBie, that same asset data usually has to be re-entered manually into the FM system, which defeats much of the purpose of having a digital model in the first place. COBie matters specifically at the handover point from construction and documentation to operations.

ISO 19650: A Management Standard, Not a File Format

ISO 19650 is an international standard for managing information over the lifecycle of a built asset using BIM. It is easy to confuse with a file format because it is so often mentioned alongside IFC and COBie, but ISO 19650 doesn’t specify any particular software or exchange format at all. Instead, it standardizes things like:

  • Common Data Environment (CDE) workflows: how information moves between “Work in Progress,” “Shared,” “Published,” and “Archived” states
  • Information requirements: defining what information is needed, by whom, and at what stage of a project
  • Naming conventions and metadata: consistent structure so files and data can be found and trusted across a project team

In practice, ISO 19650 compliance is a project-level and organizational commitment. It involves a formal accreditation process, not something a single deliverable can claim on its own. What a Scan-to-BIM provider can do is deliver in a way that’s compatible with an ISO 19650 workflow: consistent naming, a documented QC process, and both native and IFC formats available for whichever CDE or coordination platform the project uses.

What VMTS Delivers as Standard

Every VMTS Scan-to-BIM project is modeled natively first, in Revit, Archicad, Allplan, or Vectorworks, so the deliverable stays fully editable for whoever needs to keep working on it. From there:

  • Native BIM file at the agreed LOD, the primary editable deliverable
  • IFC export on request, for coordination, clash detection, or handoff to platforms that don’t need to edit the model
  • COBie export on request, for projects handing structured asset data to a CMMS/CAFM system
  • A documented QC report checking the model against the source point cloud

IFC and COBie exports are typically add-ons on top of the native file rather than a separate cost driver on their own. For a full breakdown of what actually determines the price of a Scan-to-BIM project, see our Scan-to-BIM Cost Guide 2026.

These native-first deliverables are also central to evaluating an overseas partner in the first place. See why European firms outsource Scan-to-BIM to Vietnam for how quality, data security and communication safeguards fit around a deliverable like this.

“You scan. We support all downstream services, from point clouds to native BIM models, plus whatever exchange format your workflow needs on top.”

Frequently Asked Questions

What’s the difference between IFC and a native BIM file?

A native file (Revit, Archicad, Allplan, Vectorworks) is built with the software’s own parametric elements and stays fully editable. IFC is a vendor-neutral exchange format, good for interoperability and coordination, but many imported IFC objects lose their editable, parametric behavior.

Do I need both a native file and an IFC export?

In most cases, yes. The native file is what you’d use for ongoing editing and design work; the IFC export is useful for coordination, clash detection, or sharing with parties using different software. VMTS delivers the native file as standard and IFC on request.

What is COBie used for?

COBie packages non-graphical asset data such as equipment, spaces and attributes into a structured format designed for handover to facility management systems (CMMS/CAFM). It’s most relevant at the point a project transitions from construction and documentation to operations.

Is ISO 19650 a file format like IFC?

No. ISO 19650 is a management standard for how BIM information is organized and exchanged across a project’s lifecycle, covering Common Data Environment workflows, information requirements and naming conventions. It doesn’t specify a particular file format or software.

Can a single BIM deliverable be “ISO 19650 compliant”?

Not really. ISO 19650 compliance applies at the project and organizational level, not to a single file. What a Scan-to-BIM provider can do is deliver in a way that’s compatible with an ISO 19650 workflow: consistent naming, documented QC, and native plus IFC formats.

Work with VMTS

Need native, IFC, or COBie deliverables, or all three?

Tell us your project’s workflow and downstream systems, and we respond within one business day with an initial assessment.

Nguyen Huynh (Rainer)
Nguyen Huynh (Rainer) VMT Solutions
About the Author:

Nguyen Huynh (Rainer) is Managing Director at VMT Solutions, specializing in Point Cloud to BIM workflows for surveying, planning, and engineering offices. He focuses on precise BIM models, clearly defined quality standards, and long-term technical partnerships.

Share This Story!

Our Projects

Take a look at the latest projects in various fields completed by our VMT team.

We are proud to have

satisfied customers.

We are so excited,

join our customers in conquering challenging projects.