IFC export basics: sharing Revit models in an open format

What IFC is

Industry Foundation Classes, usually called IFC, is an open data schema for describing buildings and infrastructure: their elements, spaces, relationships and properties. It is developed by buildingSMART International and published as the international standard ISO 16739. Because it is vendor-neutral, IFC is widely used for coordination between teams using different authoring tools, for model checking, and increasingly as a required deliverable in public and owner-led projects.

IFC is an exchange format, not a replacement for native authoring files. An IFC file describes the model at a point in time. Editing it back in an authoring tool is possible to varying degrees, but most exchanges treat IFC as a reference: something to view, coordinate against, check and extract data from.

Schema versions and model views

Two choices shape every IFC export:

• Schema version. IFC2x3 has been in use for many years and is still widely supported. IFC4 adds better geometry and property handling. IFC4.3 extends the schema to infrastructure such as roads, rail and bridges. The right choice depends on what your recipients' software can read reliably.
• Model view definition. A model view definition, or MVD, specifies a subset of the schema for a purpose. For IFC2x3, the Coordination View 2.0 has long been the common choice for coordination. For IFC4, the Reference View targets coordination and referencing, while the Design Transfer View aims at more editable exchange.

Do not choose these alone. Agree the schema and MVD in the BIM execution plan, and test an exchange with recipients before production starts.

How Revit exports IFC

Revit includes an IFC exporter with configurable setups. Autodesk also maintains the exporter as an open-source project, and updated versions are released separately from Revit. Check which exporter version you are using, because behavior and options change between releases.

An export setup typically controls:

• IFC version and model view.
• Which phase and which elements are exported, for example only elements visible in a chosen view.
• Whether to split walls and columns by level, export room or space boundaries, and include base quantities.
• Which property sets are included: Revit-derived sets, standard IFC common property sets, and user-defined property sets.
• How coordinates and the site placement are written.

Save named setups for each recurring purpose, such as "Coordination - IFC4 Reference View", and store them with the project template so everyone uses the same settings.

Classification: getting elements into the right IFC class

Every exported element becomes an instance of an IFC class, such as a wall, slab, door or generic building element proxy. Revit maps its categories to IFC classes by default, and the mapping can be adjusted. Individual families or types can also be directed to a specific IFC class using export parameters.

Classification errors are the most common IFC quality issue. Typical examples:

• Generic models used for real building elements, exporting as proxies with no clear meaning.
• In-place families that represent walls or roofs but export as something else.
• Families in the wrong Revit category, which carries through to the IFC class.

The best fix is upstream: correct categories in families and a library QA step that checks IFC class. The family QA checklist includes this.

Properties and property sets

IFC groups properties into property sets. Some are defined by the IFC standard, such as the common property sets for walls, doors and other element types. Others are defined by a project or organization. Recipients often look for specific properties in specific sets, for example a fire rating or a load-bearing flag in the standard common property set.

To deliver properties reliably:

1. List the properties recipients need, by element type and stage. The LOD and LOI guide covers how to tie this to purpose.
2. Identify which Revit parameters hold each value, preferably shared parameters.
3. Configure the export so those parameters map to the expected property set and property name.
4. Check the output, not just the settings.

Units and data types matter. A fire rating exported as free text in one project and a coded value in another will frustrate any automated check.

Coordinates and placement

Misplaced IFC models are a common and avoidable coordination problem. The export setup decides which Revit coordinate base is written to the IFC site placement, such as shared coordinates or the project base point. Agree with the team which base to use, set up shared coordinates consistently across models, and test with a simple exchange. If the project requires georeferencing, confirm how the recipients expect it to be expressed and check it in an independent viewer.

Checking an export before sharing

Never share an IFC export without opening it in software other than the one that produced it. A basic check:

• Opens cleanly in an independent IFC viewer without errors.
• Complete: expected elements are present; nothing that should be hidden is exported.
• Correctly placed: aligns with other disciplines' models.
• Correctly classified: walls are walls, doors are doors; few unexplained proxies.
• Properties present: spot-check required properties on a sample of elements.
• Spatial structure sensible: project, site, building and storeys are named and ordered correctly.
• Reasonable file size: unexpected size often points to detailed families or exported elements that should be excluded.

Record the export setup name and exporter version with each issued file, so recipients and future you can reproduce it.

Element identity across exports

IFC elements carry globally unique identifiers. Revit stores the identifier used for each element so that successive exports of the same element keep the same identity, which allows recipients to track changes between issues. Avoid workflows that recreate elements unnecessarily, such as deleting and redrawing instead of modifying, when stable identity matters to the recipients.

What about 2D drafting content?

IFC exchanges focus on model elements. Drafting views, detail lines and 2D annotation are generally not what recipients expect in a coordination IFC. That is one reason to keep 2D detail content in drafting views and detail components with clean, standard types: it keeps the 3D model, and therefore the IFC export, focused on building elements. When migrating CAD details, the result typically lives in drafting views; see the detail migration strategies guide.

Plan exchanges before the first export

IFC problems are easier to prevent than to fix. Before the first exchange on a project, agree the following with the receiving party and record it in the execution plan:

• Purpose. Coordination, quantity take-off, handover and viewing each need different content and different property sets.
• Schema and view. Which IFC version and model view definition the receiving software expects.
• Content. Which categories, phases and design options are included, and whether linked models are exported separately.
• Properties. Which property sets and classification are required, and where each value comes from in your model.
• Location. Which coordinate basis is used, and how it will be checked.

Then run a test exchange early, with a small model, and ask the recipient to confirm that they can read it as intended. A test at the start of a stage costs little; discovering a coordinate or mapping problem at a deadline costs a great deal.

Save and version export setups

Once a configuration works, save it as a named export setup in your template, and record which project requirement it serves. Give setups clear names that include the purpose and schema. When a setup changes, note the change and the reason, so later exports can be reproduced and compared.

Common pitfalls

• Choosing a schema or model view the recipients' software reads poorly.
• Default export settings that include every phase or hidden element.
• Proxies caused by generic models and in-place families.
• Required properties held in family parameters with inconsistent names.
• Coordinate base not agreed, causing misalignment.
• Exporter version changed mid-project without retesting.

IFC export checklist

• Schema, model view and exporter version agreed in the BEP.
• Named export setups stored with the project template.
• Category mapping reviewed; families correctly categorized.
• Required properties mapped from shared parameters.
• Coordinate base agreed and tested.
• Every export opened and checked in an independent viewer.
• Setup name and exporter version recorded with each issue.

IFC quality starts with model quality. The model health checks guide covers the routine checks that make clean exports easier.