An IFC export can preserve walls, openings, and space geometry while discarding shared parameters, family data, and material detail. That makes IFC a practical plan review exchange format, but not an automatic substitute for a native Revit model. The right choice depends on which compliance inputs the receiving tool must interpret.
This article examines IFC, Revit .rvt, and other proprietary formats, including what survives export and what does not. It also considers submissions to agencies and platforms that accept IFC alongside conventional PDF sets.
IFC Defined
IFC, or Industry Foundation Classes, is an open, neutral format for building and construction information. Defined in ISO 16739-1:2018 and maintained by buildingSMART International, it specifies how walls, doors, slabs, MEP components, spaces, and their properties are represented independently of authoring software. An IFC-conformant tool can therefore read the model without access to the proprietary application that created it.
For most commercial exchange workflows, IFC 2x3 remains the practical baseline. It was published in 2006 and still has the widest cross-platform support. IFC 4, published in 2013 and formally identified as ISO 16739:2013, adds richer geometry, stronger property set definitions, and better support for parametric and infrastructure objects. Export and receiving support remain uneven, so as of mid-2025 IFC 2x3 is still the common working standard.
Unlike a proprietary format, IFC can be written and read by conforming software without licensing the underlying schema. Revit .rvt is Autodesk's proprietary format, while ArchiCAD .pln belongs to Graphisoft. IFC files can be analyzed by compatible code checking, energy analysis, and plan review tools without exposing the authoring model.
IFC Export: Kept and Lost
Exporting a Revit model to IFC translates one data model into another, so the result is not lossless. A well-configured export usually retains wall faces, door and window openings, slab boundaries, column profiles, roof geometry, and standard IFC property sets for common elements. Space boundaries and areas, including room geometry, can support occupant load and egress calculations.
Losses commonly include Revit shared parameters without an IFC mapping, nested family data in curtain panels and parametric systems families, custom values stored on types rather than instances, graphic overrides, view filters, and complete material definitions such as textures and rendering properties. Results vary with the exporter and its settings.
Revit includes an Autodesk IFC exporter, and BIT (BIM Interoperability Tools) is available as a separate option. BIT generally maps more Revit data into IFC property sets and is usually the stronger route for compliance exports. Export settings determine which sets are included. With defaults and no property set configuration, the file may have complete geometry but little semantic data.
Agency Acceptance in Practice
PDF drawing sets remain the primary building permit submission format in the United States. Most departments are equipped to review a 2D PDF derived from the BIM model and organized according to local submittal requirements. Many jurisdictions describe BIM-native review as a goal, but actual capability and procedure differ substantially.
Some jurisdictions are developing IFC workflows. Los Angeles has operated ePlanLA, with IFC included in its longer-term BIM submission roadmap. New York City's DOB BIS accepts digital submissions. In Colorado, Denver uses ProjectDox for electronic plan review, primarily as a PDF-based platform. As of this article's publication, IFC in lieu of PDFs is not a standard workflow for Denver commercial plan review.
Kestrel Labs accepts both IFC uploads and Revit models through its plugin. IFC is portable and requires no software installation on design team machines. The native Revit route exposes more model data, especially shared parameters and family-level information that IFC may omit. For egress, accessibility, and occupancy checks based on geometry and space properties, the practical difference is small. Energy checks tied to assembly material properties benefit materially from native Revit data.
LOD and Export Fidelity
The BIMForum LOD Specification uses Level of Development to describe how fully an element is defined at a design stage. An LOD 200 wall has approximate dimensions and location. At LOD 350, its connections to adjacent elements and physical properties are specified. An LOD 400 wall has fabrication-ready geometry and specification.
LOD affects what an IFC export can support. An LOD 200 model may provide usable spatial geometry while lacking much property data and many element type assignments. At LOD 300, scheduled door and window types provide more reliable widths than placeholders, and accessible routes can be inferred from space geometry. LOD 300 is approximately the minimum useful level for IFC-based egress and accessibility checks. Envelope assembly checks for energy code generally need LOD 350 or higher.
Choosing the Working Format
For permit-ready models authored in Revit or ArchiCAD, producing an IFC export usually adds little friction and takes minutes for most models. The resulting file can go to an IFC-accepting review tool without sharing the proprietary model, an important distinction where project confidentiality or intellectual property is a concern.
IFC export quality requires active project-level management; it is not a default workflow that reliably works out of the box. Standard Revit exports can duplicate linked-model geometry, omit compliance-relevant shared parameters, and assign some elements to incorrect IFC object classes. Firms obtaining dependable compliance results typically have a BIM team member configure settings for project families and templates. Maintaining that setup in the BIM template can support later projects of the same type.
There is no universal winner between IFC and proprietary formats. The choice depends on the project, submission workflow, and data the receiving tools require. We are not saying IFC carries every compliance input; we are saying its suitability must be tested against the model and check, not inferred from the file extension.
