BCF Explained: How openBIM Teams Communicate Model Issues

Once you've got IFC carrying the model and IDS checking it against requirements, there's still a missing piece: how do the humans actually talk about what's wrong, across different software, without emailing a 400MB file back and forth every time someone spots a clash? That's what BCF is for, and it's a smaller, more mechanical standard than IFC or IDS, but a genuinely practical one.

What BCF actually is

BCF is an open standard published and maintained by buildingSMART International, alongside IFC and the Data Dictionary (bSDD). Development started back in 2009, led by Tekla, Solibri, and the Institute for Applied Building Informatics at Munich University of Applied Sciences, before it became a formal buildingSMART standard. The current file-based specification is BCF 3.0, with BCF 2.1 still widely deployed across existing software. Alongside the file format, a BCF API now exists as a RESTful web service with JSON payloads, described by buildingSMART as transforming BCF "from a static file format into a dynamic web service," complementing the file format rather than replacing it.

What's inside a BCF file

A BCF is a ZIP archive, not a single document. Inside it sit topic folders, each named by a GUID, holding a markup file, one or more viewpoint files, and screenshot images. Three data objects do the actual work:

• Topic: a GUID, type, status, priority, title, description, creator, assignee, and due date.
• Comment: a GUID, timestamp, author, text, and an optional linked viewpoint.
• Viewpoint: camera position and direction, view angle, and the specific selected or visible elements, referenced by their IFC GlobalId, plus optional clipping or section planes.

That last detail is what makes BCF practical: elements are referenced, not duplicated. A BCF file ends up a few dozen kilobytes, pointing into a model that might run hundreds of megabytes, rather than trying to carry any of that model data itself.

Where BCF sits alongside IFC and IDS

buildingSMART frames the three standards as distinct, complementary roles: IFC is the standardized digital description of the built asset itself. IDS defines the exchange requirements a model needs to meet. BCF lets different BIM applications communicate model-based issues with each other by leveraging that same IFC data, rather than being a third way of describing the model.

A typical clash-detection workflow using BCF

In practice, a coordination tool, Solibri, Navisworks, BIMcollab, or Revizto among others, runs clash detection across federated IFC models from multiple disciplines. It generates BCF topics with viewpoints pinned directly to the clashing elements, and authoring tools like Revit, Archicad, or Tekla Structures import those topics through plug-ins, jumping straight to the flagged view so the modeler can resolve the issue without hunting for it manually.

The newer BCF API pattern, sometimes called "BCF Cloud," changes the delivery mechanism rather than the underlying idea: instead of emailing `.bcfzip` files back and forth, topics and comments sync through a central server, so multiple parties see issue status updates in near real time. The spec itself works through polling on creation and modification timestamps rather than defining push or websocket notifications, so "real time" here means "fast polling," not instant push.

Where BCF actually breaks down

• Minimal compliance is barely useful. Only a topic's GUID and title are mandatory fields. A minimal export carries "little more information than an informal email notification," which defeats most of the point of using BCF in the first place.
• Different tools implement the optional fields inconsistently. One documented case found Navisworks capturing only camera position and timestamp, omitting priority, assignee, and status entirely, while Bentley's ProjectWise has richer fields but sits in a closed ecosystem that doesn't interoperate the same way with outside BCF tools. Not every "BCF-compatible" tool round-trips the same information.
• Two serializations, one spec, occasional drift. Because BCF exists as both XML (file) and JSON (API), researchers flag a real maintenance burden and the risk of subtle semantic differences between the same issue expressed two different ways.
• It's an issue tracker, not a project management system. BCF has no native fields for issue interdependencies, cost impact, or risk, so teams that rely on it for those things are asking it to do a job it was never built for.
• Nobody owns closing the issue by default. A documented mega-project case found Navisworks viewpoints, ProjectWise Issue Resolution, and BIMcollab/BCF all coexisting in parallel without one unified source of truth for who actually resolves an issue. BCF carries the conversation, it doesn't assign the accountability, that's still a decision your own process has to make explicitly.

Frequently asked questions