How to export from Revit to IFC with all your parameters (Psets and stages) without losing your mind

Interoperability · 15 min · 2026-08-06

The definitive guide to exporting a Revit model to IFC carrying the right parameters, correctly named and placed in their Property Sets (Psets), meeting the Level of Information Need (LOIN) per project stage. Custom property sets, shared parameters, mapping file, IFC class (IfcExportAs) and a verification checklist.

It is one of the biggest frustrations of real-world BIM: you have an impeccable Revit model —parametrized, tidy, with all the information filled in— and when you export it to IFC to deliver it, you open the file in another program and it is a mess. Parameters are missing, others arrive with strange names, and the data you worked so hard to fill in simply did not travel. And if the client requires you to meet information requirements per stage with specific parameters, the problem becomes a serious headache.

This guide is precisely about not "losing your mind along the way". We will explain why this happens and, above all, how to export from Revit to IFC carrying all the expected parameters, correctly named and placed in their Property Sets, so they can actually be used in the receiving software. This is the heart of openBIM interoperability.

Why a perfect Revit model exports badly to IFC

The root cause is easy to understand: Revit and IFC are two different languages. Inside Revit your parameters live in Revit's own parameter groups (Identity Data, Dimensions, Data, etc.). But the IFC format has no such groups: it organizes information in structures called Property Sets ("Psets").

When you export, Revit has to translate your native parameters into IFC Psets. If you do not tell it exactly how to do that translation, one of three things happens:

  • The parameter is not exported (it stays in Revit and never reaches the IFC).
  • It is exported, but with a different name or inside a generic Pset where the receiving software does not look for it.
  • It is exported empty because the data was in a parameter of a different type than the standard expected.

The good news: the translation can be controlled precisely. You just need to know which levers to pull.

Key concept: what a Property Set (Pset) is and why it matters

A Property Set is simply a named "box" that groups properties inside the IFC. For example, Pset_WallCommon is buildingSMART's standard box for a wall's common properties (IsExternal, FireRating, LoadBearing, etc.).

When a standard or a client asks you for "parameter X", they are actually asking for a property with an exact name, inside a Pset with an exact name. If your data arrives with the correct name but in the wrong box —or with the correct box but a misspelled name— then for the receiving software that data does not exist. That is why interoperability is not just "the data travels", but that it travels named and placed where it belongs.

There are two main types of Psets:

  • buildingSMART standard Psets (they start with Pset_): defined by the IFC schema, such as Pset_WallCommon, Pset_SpaceCommon, Pset_DoorCommon. Revit can map several of them automatically.
  • Custom Psets: the ones you (or the client) define for specific requirements, for example a Pset_Identification with the fields the standard requires at a given stage.

The 3 ways to export parameters from Revit to IFC (worst to best)

Way 1: "Export Revit property sets" (fast but dirty)

In Revit's IFC export options there is a checkbox "Export Revit property sets". If you enable it, Revit exports your parameters grouped into Psets with names like PSet_Revit_<Group>.

Problem: the names are not what the standard asks for, and everything is exported, creating noise. It works as a safety net so you do not lose information, but it does not meet a specific naming requirement. Use it only as a backup, not as your main method.

Way 2: "Export IFC common property sets" (for the standard Psets)

The "Export IFC common property sets" checkbox makes Revit automatically fill the buildingSMART standard Psets (Pset_WallCommon, etc.) from their equivalent native parameters. Always enable it. It covers the basic properties well, but it does not cover a client's custom requirements or a specific project stage.

Way 3: A "user-defined property sets" file (the correct way)

This is the professional way and the one that lets you meet demanding requirements. It consists of a text mapping file where you define, with total precision:

  • The exact Pset name (exactly as the standard requires).
  • Which IFC entities it applies to (walls, doors, spaces...).
  • Whether it is at Instance (I) or Type (T) level.
  • Which Revit parameter feeds each IFC property, and the data type.

In the IFC export options, on the property-content tab, you enable "Export user-defined property sets" and point to your .txt file. The format of each block looks like this:

PropertySet: <PsetName>  I  <IFCEntities>
  <IFCPropertyName>  <DataType>  <RevitParameter>

A concrete example for an identification requirement:

PropertySet: Pset_Identification  I  IfcWall,IfcSlab,IfcColumn,IfcBeam
  Code  Text  PB_Code
  Room  Text  PB_Room
  Classification  Text  PB_Classification

With this you are telling Revit: "take my parameter PB_Code and export it as the property Code (text type) inside the Pset Pset_Identification, on walls, slabs, columns and beams". The result arrives exactly in the other software.

Use SHARED parameters, not project parameters

A detail that ruins many exports: for a parameter to behave stably on export (and be schedulable), create Shared Parameters, not loose project parameters. Shared parameters have a unique identifier (GUID), which makes them predictable and reusable across projects and templates. Keep your shared-parameter file next to your IFC mapping file: they are the duo that standardizes your office.

Practical tip: define your own prefix for your shared parameters (for example PB_) to tell them apart at a glance and avoid clashes with native parameters.

When the native parameter "does not fit" the IFC

Sometimes the data exists in Revit but in a parameter of an incompatible type: a numeric value stored as text, an area Revit handles as an internal dimension, a boolean that in Revit is Yes/No but IFC expects as IfcBoolean. Rules to avoid failing:

  • Declare the correct data type in the mapping file (Text, Real, Integer, Boolean, Area, Volume...).
  • If the data is in a native parameter you cannot export cleanly, create a "bridge" shared parameter and copy the value into it (with a schedule or an add-in) before exporting.
  • Do not mix units: verify the project units match what the receiver expects (meters, m², etc.).

The correct IFC class: IfcExportAs (the life-saving parameter)

Another classic: you export a family and it arrives in the IFC as IfcBuildingElementProxy (a "generic box") instead of its real class. That breaks filters, quantities and validations. The solution is the special parameter IfcExportAs: you create that parameter (project or shared) and write the target class, for example IfcFurniture or IfcDoor. With IfcExportType you can also set the predefined subtype. There are also IfcName, IfcDescription and IfcTag to control how each element is identified.

Additionally, Revit allows a class mapping file (Revit Category → IFC Class) in the export options: this ensures, in one go, that each category lands on its correct IFC entity.

Parameters per stage: Level of Information Need (LOIN)

This is the part that bites hardest on regulated public projects. A good BIM standard does not ask for "all parameters always": it asks for a different Level of Information Need (LOIN) depending on the project stage. The more advanced the stage, the more information is required per element.

The practical logic of which parameters you must have filled in:

  • Early stages (concept, preliminary): basic identity and naming are enough —that the element exists, has a name and is roughly well classified.
  • Detailed design: real classification and material are required, on top of naming. This is where most deliverables start to fail.
  • Construction / manufacturing / as-built: element-specific technical properties (dimensions, performance, manufacturer, model).
  • Operation and maintenance: information to operate and maintain the asset throughout its service life.

The consequence for your export is clear: define your custom Psets per stage. Do not export every possible field at concept design, nor deliver an as-built with only naming. The mapping file lets you keep one property set per project moment.

IFC 2x3 or IFC4: watch the Pset names

Standard Psets change slightly between IFC 2x3 and IFC 4 (some properties were renamed, added or moved). If your client asks for a specific version, export in that version and check the common Pset names in that schema edition. For your custom Psets you control the name, so they do not change; the care goes into the Pset_..Common ones. (If you want to dig deeper, see our article on the differences between IFC 2x3 and IFC4.)

Step by step: a "by the book" IFC export from Revit

  • 1. Create your shared parameters (with your own prefix, e.g. PB_) and load them into the model.
  • 2. Fill in the real data in those parameters (schedules are faster and let you spot blanks at a glance).
  • 3. Prepare your user-defined property sets mapping file (.txt) with the correct Psets, properties, data types and entities for the stage you are delivering.
  • 4. Assign the correct IFC class with IfcExportAs where needed, or use the class mapping file.
  • 5. In File → Export → IFC → Modify setup: choose the requested IFC version (2x3 or 4), enable "Export IFC common property sets", enable "...user-defined" and point to your .txt, and set the shared coordinates.
  • 6. Export and verify the result in a neutral IFC viewer (not in Revit): confirm each property is in its Pset, with its name and the data filled in.

Verification checklist before delivering

  • Does each element have its correct IFC class (no accidental IfcBuildingElementProxy)?
  • Do the Psets have the exact name the standard or client requires?
  • Are the properties spelled correctly (case, no extra spaces) and with the correct data type?
  • Are the fields filled with real data, not empty?
  • Does the information match the LOIN required by the stage you are delivering?
  • Did you open the IFC in a neutral viewer to confirm everything travelled correctly?

Automate the verification with BIMaudit

Reviewing by hand, element by element, whether each property reached its Pset and whether the model meets its stage LOIN is slow and error-prone. That is exactly why BIMaudit exists: you upload your IFC and in minutes you get a 100% deterministic report that verifies naming, classification, materials, properties per LOIN and stage coherence against a public standard aligned with ISO 19650, with a compliance traffic light and the detail of each finding. So before delivering to the client you know exactly which parameters are missing or arrived wrong and can fix the export before it is rejected. Try it for free with a model at bimaudit.io.

Audit your IFC model for free with BIMaudit