IFC in Revit: how to link, open and export IFC files

IFC and Revit meet in two directions. Someone sends you an IFC and you need it in your Revit model; or you have a Revit model and someone needs an IFC. Both are routine, both are documented, and both go wrong in the same few ways. This covers each direction and the one decision that matters most in each — link or open on the way in, the export setup on the way out.

The last part is first-hand. On our reference buildings, AutoIFC’s models are scored against the surveyors’ own IFCs, and those references are Revit exports. Measuring against them element by element shows what a Revit IFC export actually contains, which is not always what the person who exported it believed.

Bringing an IFC into Revit: link or open

Revit offers two routes, and they produce different things.

Link IFC

Insert › Link IFC, pick the file, choose how it is positioned. The IFC appears in your project as a linked model, read-only, the same way a linked Revit model does.

Behind the scenes Revit converts the IFC into a helper file in the same folder, named after it with .ifc.RVT appended — facade.ifc gets a facade.ifc.RVT beside it. That helper is what your project actually references. Two consequences:

• Do not move it, rename it or edit it. Revit relies on it to maintain the link. Editing it breaks the ability to update from the IFC.
• Updates are a reload. When a new version of the IFC replaces the old one at the same path, reloading the link rebuilds the helper and your project shows the new model. Anything you changed inside the helper is lost at that point, which is the other reason not to touch it.

Open IFC

File › Open › IFC converts the file into a Revit project. Elements are mapped to Revit categories — an IfcWall arrives in Walls — but as DirectShape geometry: shapes with a category, not parametric elements. You cannot change a DirectShape wall’s type, cut an opening in it or join it to another wall. Opening is usually recommended for an IFC that was exported from Revit in the first place; for anything else, it is a way to look at the model inside Revit rather than to continue it.

Can IFC elements become native Revit elements?

Not with Revit alone. Linked or opened, IFC elements are DirectShape, and Revit has no command that rebuilds a DirectShape wall as a system-family wall. The IFC itself is not the obstacle — it says clearly that the object is a wall of a given thickness — but Revit’s importer does not infer wall types, joins or hosting.

Two routes exist when you genuinely need editable elements:

• Conversion add-ins read a linked IFC and create native walls, floors, columns, doors and windows, some also turning IFC property sets into shared parameters.
• Dynamo scripts do the same thing for the classes you choose, which is often enough when you only need the walls rebuilt.

Either way, treat the result as a remodel, not a translation. The converter has to pick a wall type for every wall and decide how walls join, and those decisions are not in the IFC. Check thicknesses and openings against the source before designing on it, and accept that the converted model no longer updates from the IFC.

Before you link: four things to check in the IFC

Most “Revit won’t import this” problems are visible in the file before Revit is involved. Open it in a viewer first — our free IFC viewer reads IFC2x3 and IFC4 in the browser without uploading anything — and check:

• The schema. FILE_SCHEMA in the header says IFC2X3 or IFC4. Current Revit reads both; an older installation may not read IFC4.
• The model view definition. A Reference View file is exported for looking at, with simplified geometry. Expect reference quality, whichever route you take.
• The classes. Count the IfcBuildingElementProxy elements. A handful is normal; hundreds means the exporter did not know what things were, and they will land in Generic Models.
• Where it sits. If the model appears kilometres from your project, it is positioned by coordinates Revit does not share with your project — see the georeferencing finding below before assuming the file is wrong.

What those header lines and classes look like in an actual file is in What is an IFC file?

Exporting IFC from Revit

File › Export › IFC. The dialog offers named setups; choose one, or duplicate a built-in setup and modify it. Revit’s IFC exporter is Autodesk’s own open-source project, revit-ifc on GitHub, which Revit and Revit LT use from 2019 onwards, so behaviour changes between Revit versions and add-in releases — worth knowing when two colleagues get different results from the same model.

The setup is organised in tabs — General, Additional Content, Property Sets, Level of Detail, Advanced — and the first decision is the version and view:

The export settings that decide whether the file is usable

The GUID option does not reach elements that come from linked Revit models. If a project is exported with its links, the linked elements’ GUIDs are not written back and can change between exports.

What we found in real Revit IFC exports

AutoIFC is scored against surveyors’ own models, element by element, so we read Revit IFC exports far more closely than anyone who only links them. They are real project exports, not test files; each point below is measured, and each is invisible when the file is merely looked at.

The site was never located

In two unrelated exports, the site’s latitude and longitude were Revit’s default location, Paris — the template value, never changed. The file looked georeferenced and was not. Do not treat an IFC’s site coordinates as a coordinate reference system unless whoever exported it confirms they set them.

Terrain outweighed the building

In one export, 55 % of the model’s 5,113 m² of surface was terrain: six topography solids exported as IfcBuildingElementProxy. The building itself was 175 elements and 2,173 m². Nothing was wrong with the building; the export simply was not scoped to it. “Export only elements visible in view”, from a view with topography hidden, prevents it.

One product, many pieces

A Revit wall sweep interrupted by the windows it runs past exports as one IFC product holding several disjoint solids. Read as one object, a building’s 15 sill bands appeared up to 35.6 m long; they were 40 separate pieces of at most 2.4 m — 206 m of moulding counted where 60 m exists. Anything downstream that measures per product, rather than per solid, will be wrong in the same way.

Family conventions travel into the IFC

On several models the IFC window sat 21 mm above the bottom of its own opening, flush on the other three edges. That is a property of the window family, not of the building: on a later export of another building it was 0 mm, and on a model drawn in feet it was −76.2 mm — exactly three inches. A dimension read from an exported IFC is the family’s dimension until it has been checked against the building.

The model was more orthogonal than the building

On one building the two street faces meet at 90.785°; the model has them at 90.000°. The same model was three discipline models merged, in feet, which did not share one offset — the positions disagreed by several hundred millimetres between blocks. Shared coordinates across linked models before export, and a model drawn to the survey rather than to a nominal grid, are what prevent both.

The export we measured against was out of date

One reference we used was a 22 May export at 36 saves. The same Revit project had since been exported again, twice; the current file was from 3 June at 86 saves — and a property we had measured on the old export was not in the new one. We scored against the superseded file for months before noticing. Name exports with a date or version, keep one current, and when a result surprises you, check which export it came from before you check anything else.

Two conventions worth knowing

• Storeys follow levels, not position. An export filed 13 of 15 elements in the band between two floors under the storey above: Revit’s level association, not where they physically are.
• A roof can be a container. A sloped glazed roof exported as an IfcRoof with no geometry of its own; every triangle was on its mullion and panel children. Filter by class and the roof looks empty.

A round trip that holds up

• Exporting: scope with a 3D view, set Coordinate Base to shared coordinates on a multi-model project, store IFC GUIDs, choose the view for how the file will be used, and date the file name.
• Checking: open the IFC in a viewer before sending it — schema, class counts, proxies, and whether terrain or context came along.
• Receiving: link rather than open, leave the .ifc.RVT helper alone, and reload when a new version arrives at the same path.
• Converting: only if you must edit, knowing the model stops updating from the source.

Where AutoIFC’s IFC fits

AutoIFC turns a laser scan into an IFC model of a building’s facade. What you download is IFC4, written by IfcOpenShell with a Design Transfer View header, one GlobalId per element, walls, windows and doors as typed elements and vents as proxies, all carrying our own property set — facade, confidence, what was inferred rather than measured, and review state. For a survey model the advice above applies: link it, and reload when a revised run replaces it. How the model is produced is on Point cloud to IFC, and what it gets right on a surveyed building is on the Accuracy page.

In short

Link an IFC into Revit when you design against it, and open it only to inspect it; either way its elements are DirectShape, and making them native is a remodel through an add-in or Dynamo. On export, the settings that matter are the view, the coordinate base, scoping to a view, stored GUIDs and class mapping. And whichever direction you are going, look at the IFC itself before trusting it: in real Revit exports we have found a site left in Paris, terrain outweighing the building, mouldings measured at three times their length, window families 21 mm off their openings, and a reference that had been superseded twice.