IFC is meant to be the great equalizer — open, vendor-neutral data exchange between Revit, ArchiCAD, Tekla, and everything else. In practice, a default IFC export from Revit drops or mangles more data than most teams realize until a downstream tool (a clash checker, an energy model, a client's own viewer) flags something missing. Here are the seven issues I run into most often, and the fix for each.
1. Parameter mapping isn't automatic — it has to be configured
Revit doesn't automatically know that your "Fire Rating" parameter should map to the IFC property set Pset_DoorCommon.FireRating. Without an explicit mapping file (an IFC export parameter mapping table), custom parameters either get dropped entirely or exported as generic, unmapped properties that downstream software can't recognize. The fix: maintain a project- or office-level IFC mapping file that explicitly ties your shared parameters to the correct IFC property sets.
2. Family categories exporting to the wrong IFC entity
A custom family modeled under the wrong Revit category (a common issue we cover in our family creation mistakes guide) will often export to an incorrect or generic IFC entity type, breaking any downstream filtering or scheduling based on IFC classification. Fixing the Revit category before export solves this far more reliably than trying to patch it after the fact.
3. Linked models not included or incorrectly positioned
If linked models aren't set to export, or shared coordinates aren't correctly established, the resulting IFC file may be missing entire disciplines or have them positioned incorrectly relative to each other — the same shared-coordinate issue that affects Navisworks federation (see our federation guide) applies equally here.
4. Default export configuration is too aggressive at simplifying geometry
Revit's default IFC export settings prioritize smaller file size, which can simplify complex geometry (curved walls, custom profiles) in ways that lose fidelity needed for downstream structural analysis or fabrication. Review and adjust the geometry export options rather than accepting defaults blindly, especially on projects with non-standard geometry.
5. Phasing and design options exporting inconsistently
If phasing isn't set up cleanly (see our phasing and design options guide), an IFC export can include demolished elements that shouldn't be there, or omit elements that should — because the export respects whatever phase filter was active on the view used for export, which isn't always the one you intended.
6. Type vs instance parameters mapping to the wrong IFC level
IFC distinguishes between type-level and instance-level properties just as Revit does, and a parameter set at the wrong level in Revit will export at the wrong level in IFC — meaning a property that should vary per instance ends up locked at the type level in the exported file, or vice versa.
7. No validation before handing off the file
The single most preventable issue: exporting and sending an IFC file without opening it in a free IFC viewer to spot-check that key data actually survived the export. A five-minute validation check catches most of the above issues before they become someone else's problem on a different software platform.
A practical pre-export checklist
| Check | Why |
|---|---|
| IFC parameter mapping file reviewed and current | Prevents silent data drop on custom parameters |
| Family categories verified | Ensures correct IFC entity classification |
| Shared coordinates confirmed across all links | Prevents positioning errors in the exported file |
| Export opened in an IFC viewer before sending | Catches issues before the client/partner does |
IFC export configuration and validation is part of the interoperability training in our Apex plan. Full curriculum on the Programs page.
