BCF BIM Collaboration Format: open issue tracking for multi-tool projects (2026)

BCF (BIM Collaboration Format) is buildingSMART’s open standard for coordination issue tracking between BIM tools. BCF-XML 3.0 was released on the buildingSMART GitHub on 18 June 2021. Where IFC carries the model, BCF carries the issues, clashes, and requests about that model, and works across any tool that implements it.

Key BCF numbers at a glance

BCF is free and openly specified. The file-based specification is BCF-XML (github.com/buildingSMART/BCF-XML) and the server specification is BCF-API (github.com/buildingSMART/BCF-API); they are separate specifications.

What is a BCF topic, and what does it contain?

A BCF topic is the unit of issue in BCF: a coordination problem, clash, or design query that travels between disciplines without exporting a new model version. A topic packages the issue with enough context for the receiving party to find it in their own tool.

In a BCF file each topic is stored in a folder named by its GUID, with a markup file and optional viewpoint and snapshot files. Topic types such as clash, request for information or issue, and statuses such as open or closed, are the values a project lists in extensions.xml; two projects may use different lists.

Why BCF exists: the coordination problem it solves

Before BCF, multi-discipline coordination relied on one shared authoring tool, which is practical only within a single firm, or on screenshots and emails with no element reference and no machine-readable closeout.

BCF was designed as the issue-exchange layer next to IFC’s model-exchange layer. When a structural engineer finds a clash between a beam and a duct in a federated model, BCF is how that finding travels to the MEP engineer with a viewpoint and element references. BCF-API lets a server mediate topics instead of files being handed over; BCF-API exists for versions 2.1 and 3.0.

How does BCF connect to IFC and the CDE in practice?

BCF, IFC, and the common data environment each handle a distinct layer.

A typical loop: each discipline shares its model, clash or rule checks run on the federated model, findings export as BCF topics, each discipline imports the BCF into its tool, navigates via the viewpoint, resolves the issue, and updates the topic status.

BCF topics reference elements by IFC GUID (IfcGloballyUniqueId), not tool-internal IDs. A reference resolves in another tool only if the authoring tool preserves each element’s GUID when it exports IFC, so test this with your tools at the start of the project.

What is the difference between BCF-XML and BCF-API?

BCF-XML and BCF-API are separate specifications for the same kind of issue data. BCF-XML packages topics into a zip file for file-based handover. BCF-API exposes topics through a REST interface on a server.

Check each tool’s documentation for the BCF-XML and BCF-API versions it supports (for example, some products support BCF-XML 2.1 and 3.0). BCF-API needs a server, either a platform that implements it or a standalone BCF server.

BCF vs proprietary issue tracking: which should you use?

Proprietary issue trackers (for example tracking built into one authoring product) work inside one tool or closed team. BCF is designed to work across tools that implement it. The difference matters on any project where more than one authoring environment is active.

Common mistakes when using BCF for coordination

Three mistakes appear in BCF-based workflows.

1. Using BCF without IFC as the exchange format. Component references are IFC GUIDs. When a discipline works from files that do not carry them, “select the element” fails, though the viewpoint still works.

2. Conflating a BCF topic status with a CDE state. A topic status says where an issue stands. A CDE state says where an information container stands. Closing a topic does not confirm the model was updated; verify model changes against the topic.

3. Creating topics without viewpoints. A topic can exist without a viewpoint, but the receiving party then has to locate the issue manually in a large federated model.

Frequently asked questions

What is BCF in BIM coordination?

BCF (BIM Collaboration Format) is buildingSMART’s open standard for exchanging coordination issues between BIM tools. A topic carries a title, description, viewpoint, element references (IFC GUIDs), comments, type, status and assignee. BCF-XML 3.0 was released on 18 June 2021.

What does a BCF topic contain?

A topic contains a title and description, a viewpoint (camera position and snapshot), component references to IFC elements, comments, a required topic type and topic status, and optional priority, due date and assignee. The allowed topic types and statuses come from the project’s extensions.xml.

What is the difference between BCF-XML and BCF-API?

BCF-XML packages topics in a zip file for file-based handover. BCF-API exposes topics through REST endpoints on a server. They are separate buildingSMART specifications.

Why does BCF use IFC GUIDs instead of tool-internal element IDs?

Tool-internal IDs mean nothing to another tool. An IFC GUID is a global identifier carried in the IFC file, so a receiving tool can find the same element if the authoring tool kept the GUID when exporting.

Is BCF required by ISO 19650?

No source we could check shows ISO 19650 naming BCF as a required or recommended format. A project may specify BCF for coordination issues in its EIR or BEP. Check the project documents; the BCF specification is free at technical.buildingsmart.org/standards/bcf.