How to export Revit models to IFC (settings that matter)

Count the people on your project who need the model, then count the Revit seats. The gap between those two numbers is why the IFC export — not the .rvt — is the deliverable most of the project actually consumes. The client, the contractor, the cost consultant, the coordinators from every other discipline: what they open, question and price is the file you produce at File → Export → IFC. Which makes that unassuming dialog one of the highest-stakes screens in Revit.

Run it on defaults and you can ship a file where half the model quietly stayed home: elements demoted to anonymous proxies, zero quantities, custom parameters missing, geometry floating kilometres from where the federation expects it. None of that is a Revit defect — it's five settings, each with one job. This guide walks them in order, then shows how to verify the result exactly the way its receiver will. (If you're on the other end of this exchange — someone sent you an .rvt and you have no Revit — start with how to open a Revit file online without Revit instead.)

1. Pick the setup: IFC4 Reference View vs IFC2x3 CV 2.0

The setup dropdown at the top of the dialog bundles a schema and a set of exchange rules, and it's the decision everything else sits under. IFC4 Reference View is the modern choice for coordination and review exchanges — geometry and data packaged for people who will inspect the model, not re-author it. IFC2x3 Coordination View 2.0 is two decades older on paper yet still the required default in a large share of BIM Execution Plans, because plenty of downstream pipelines were built around it and never moved.

So the correct setup is not the newest one — it's whatever the receiving side mandates. Read the BEP; if it names a schema and a view definition, that line overrides any preference of yours. Only when nothing is specified should you default to IFC4 Reference View for viewing exchanges, and even then it's worth a one-line email to confirm before a milestone.

2. Class mapping: kill the proxies

Revit thinks in categories; IFC thinks in classes. A translation table connects the two, and every category the table doesn't cover — plus every element authored in the wrong category, like a wall modelled as a generic model — falls back to IfcBuildingElementProxy. A proxy is a shrug: geometry with no identity. Downstream, clash rules that target ducts skip it, filters that select structure ignore it, and takeoffs that key off classes count it as nothing.

Open the mapping table from the export setup and hunt for categories mapped to nothing or to proxy. Map them to real classes, and push the fix upstream too: elements modelled in their proper categories export themselves correctly without table surgery. A delivery where a third of the tree reads "proxy" tells the receiver more about your process than you'd like.

3. Property sets: the data half of the model

Geometry without data is a rendering, not a BIM deliverable. Two options in the property tab decide which side of that line your export lands on. "Export IFC common property sets" writes the standardized Psets — Pset_WallCommon with its fire rating and load-bearing flag, and its siblings for every other class. Keep it on unless the BEP explicitly trims the payload.

Custom and shared parameters are the trap: they do not travel by default. If the BEP requires project-specific parameters — classification codes, status fields, asset tags — you need a user-defined parameter mapping file, a small text file telling the exporter which Revit parameter lands in which IFC property set. Skip it and that data silently stays in the .rvt, and nobody notices until the receiver's checks fail.

4. Base quantities: don't starve the takeoff

"Export base quantities" writes each element's areas, volumes and lengths into quantity sets. Leave it off and the cost consultant opens a model full of shapes and empty of numbers — the single most common reason a QTO team bounces a delivery back. If anyone downstream measures, prices or schedules from your model, this box is on. Full stop.

5. Site placement: shared coordinates or a floating model

The site placement option chooses the origin your export is measured from: the project's internal origin or the shared coordinate system. Alone in a scene, either works. Federated with other disciplines, only one does — on a multi-model project, export from shared coordinates like everyone else, or your model materialises offset from the rest, sometimes by kilometres. It's the most common "your model is in the wrong place" ticket in coordination, and the fix is one dropdown.

Scope and weight: export what the exchange needs

Two more levers control file size. Export only elements visible in view lets you drive the export from a dedicated coordination view — furniture hidden, out-of-scope links unloaded — instead of dumping the whole database. And the level of detail setting governs how finely curved geometry is tessellated; maximum detail on a pipe-heavy MEP model buys visual smoothness nobody asked for at a real cost in megabytes. Every viewer parses a lean file faster — the browser viewer flags files past 150 MB and tops out around 300 MB depending on the machine's RAM. If a scoped export still comes out heavy, run it through the IFC compressor before it goes out.

Verify the export the way the receiver will

The worst QA plan is attaching the file unopened. The best one costs five minutes and needs no software: drop the export into the browser viewer — it parses locally on your machine, nothing is uploaded — and read what the receiver will read. The status bar's schema badge is your first checkpoint: it states what the file actually is, so a setup mistake (you meant IFC4, the badge says IFC2X3) surfaces before the file leaves the building. The item count next to it catches truncated or half-written exports at a glance.

Then go three levels deeper. Walk the model tree: storeys should read as storeys, and a wall of proxy entries means the mapping table needs another pass. Click a few elements and check their Psets in the properties panel — is the fire rating there? The custom parameter the BEP demanded? Next, run the file through the IFC validator for the structural audit: truncation, dangling references, duplicate GlobalIds. Finally, extract the model to Excel and confirm the quantity columns hold numbers, not blanks. Five minutes, and you've re-created every check the receiving BIM manager will run — before they run it.

Common failure modes, mapped to their fix

Almost every bad Revit-to-IFC export is one of five stories, and each points straight back at one setting:

Everything is a proxy. The tree is a list of IfcBuildingElementProxy. Fix the class mapping table and re-check the authoring categories.

No quantities anywhere. Base quantities was off. Enable it, re-export, verify in Excel.

The model floats in space. Wrong coordinate base. Switch site placement to shared coordinates and re-export — don't let anyone "fix" it by moving geometry.

Custom data went missing. No user-defined mapping file. Write one, wire the BEP parameters into Psets, re-export.

The file is enormous. Whole-database export at maximum tessellation. Scope it to a coordination view, drop the level of detail, and compress what remains.

Tape that list next to the export dialog and your IFCs stop being a lottery. The receiver opens a model that lands in the right place, knows what its elements are, and carries the data the project agreed on — which is the entire job of an export.