Introduction
Building Information Modelling (BIM) is revolutionising the way the construction industry operates, allowing various stakeholders to collaborate efficiently on a single platform. One of the core principles enabling this revolution is the Industry Foundation Classes (IFC), an open, neutral data format that enables interoperability between different BIM software. However, achieving a seamless data exchange through IFC export settings remains a challenge for many professionals.
The difficulty is not merely technical. It is organisational. A structural engineer exporting an IFC from Tekla Structures and an architect importing it into ArchiCAD are working with fundamentally different interpretations of what a "wall" or a "column" means at the schema level. Without deliberate configuration on both sides of the exchange, information degrades silently — geometry survives but property sets vanish, or classification codes arrive intact but materials are stripped. This blog post delves into how to master IFC export settings for achieving reliable round-trip data between BIM authoring tools, covering the technical mechanics, real-world implementation steps, and the business consequences of getting it right.
The Importance of IFC in BIM Workflows
In the world of BIM, having a file format that various software platforms can read and interpret is crucial. IFC — maintained by buildingSMART International — makes it possible to share BIM data across different tools without losing the accuracy of design information. This interoperability is particularly valuable when different project stakeholders use a variety of software: architects on ArchiCAD, structural engineers on Revit, MEP consultants on MagiCAD, and contractors using Navisworks or Solibri for coordination and model checking.
What makes IFC especially powerful is its schema depth. IFC4 ADD2 TC1, the most widely deployed stable release, defines over 770 entity types — from IfcWall and IfcBeam through to IfcZone and IfcSystem. When correctly populated, a single IFC file can carry geometry, spatial hierarchy, material layers, fire ratings, energy properties, cost data, and maintenance schedules simultaneously. The challenge is that authoring tools only expose a fraction of that richness through their default export dialogs, and most teams never touch the advanced configuration options.
A poorly configured IFC exchange produces what practitioners sometimes call "geometry-only BIM" — visually complete but informationally hollow. On a large hospital project, for instance, receiving a geometry-only IFC from the structural team means the cost manager cannot extract quantities automatically, the facilities manager cannot populate the asset register, and the MEP coordination team cannot validate clearances against fire-rated assemblies. The downstream rework cost from a single mis-configured export can run to tens of thousands of pounds across a project lifecycle.
Key IFC Export Settings
When exporting an IFC file, there are several settings that require deliberate attention rather than reliance on software defaults.
1. Model View Definition (MVD)
An MVD specifies a subset of IFC data tailored for specific workflows. Selecting the wrong MVD is one of the most common sources of silent data loss. The principal MVDs in active use are:
- Coordination View 2.0 — the legacy workhorse for multi-disciplinary coordination. Widely supported but based on IFC2x3 and limited in property coverage.
- Reference View — introduced with IFC4, optimised for geometry-heavy downstream uses such as visualisation and clash detection. Geometry is tessellated and non-editable by design.
- Design Transfer View — also IFC4-based, preserves parametric intent and editable geometry. Required when the receiving party needs to modify the model rather than simply review it.
- BIM Collaboration Format (BCF) — not an MVD per se, but tightly coupled with IFC workflows for issue tracking.
The practical rule is straightforward: use Reference View for coordination and review, use Design Transfer View when the model will be re-authored downstream. Using Coordination View 2.0 on a project targeting IFC4 compliance introduces avoidable schema mismatches.
2. Geometry Export Options
Geometry export controls how solid objects are encoded within the IFC file. The two principal representations are:
- B-Rep (Boundary Representation) — encodes surfaces as a collection of faces. Universally readable but produces large files and can cause performance issues in model checkers with complex geometry such as curved facades or organic forms.
- Swept Solid / Extrusion — encodes linear members and slabs as profiles swept along a path. More compact, faster to process, and more reliably round-tripped back into parametric authoring tools.
- Tessellation / STEP faceted B-Rep — used in Reference View exports. Irreversible simplification; suitable for review, not for re-authoring.
In Revit, the "Export as" option within the IFC Export Setup dialog governs this choice. Setting elements to export as "IfcBuildingElementProxy" when their native type is not mappable to a standard IFC entity is preferable to allowing the software to assign incorrect classifications silently.
3. Property Sets
Property sets (Psets) are the mechanism through which non-geometric data travels in an IFC file. Standard Psets — such as Pset_WallCommon, Pset_DoorCommon, and Pset_SpaceCommon — are defined by the IFC schema and should always be exported. Custom Psets, containing project-specific data such as NRM cost codes, COBie fields, or client-specific asset tags, require explicit mapping configuration.
In Revit, this is handled through the IFC Export Mapping File (a plain-text .txt file or the newer .ifcexportcfg XML format). Each Revit shared parameter can be mapped to a named Pset and property. On a commercial fit-out project, for example, mapping the Revit "Asset Tag" shared parameter to Pset_ManufacturerTypeInformation.ArticleNumber ensures the facilities management team receives structured asset data without manual re-entry.
ArchiCAD handles Pset mapping through its IFC Manager, where Classification Systems and Properties are linked to IFC domains. The same discipline applies: export profiles should be saved as named templates and version-controlled alongside the model files.
4. Units and Measurement
Mismatched units are among the most reliably destructive IFC export errors, because many viewing tools silently accept the wrong values and display geometry at the wrong scale without warning. The IFC schema encodes units in IfcUnitAssignment, and this block must be consistent with the authoring tool's internal project units.
The specific pitfalls to verify before every export:
- Millimetres vs. metres — Revit's internal unit is decimal feet, and the IFC exporter must be set to project units, not internal units. A model exported in feet and imported into software expecting millimetres will appear 305 times too large.
- Degrees vs. radians — angular units affect rotation of components and is particularly consequential for structural analysis exports.
- Currency — relevant when exporting cost data via Psets; mismatched currency codes produce incorrect quantity take-offs.
Establish a project-level IFC Export Template at the outset of every project and lock the unit settings. Share this template with all authoring parties as part of the BIM Execution Plan deliverables.
5. Layer and Classification Mapping
Classification mapping links IFC entities to recognised classification systems — Uniclass 2015, OmniClass, NBS, or client-proprietary systems. When correctly configured, every IfcProduct in the file carries a IfcClassificationReference that downstream tools can use for filtering, scheduling, and cost mapping.
In Revit, classification data is written into the export via the Revit Type Catalogue, shared parameters, or the built-in Classification Manager. In ArchiCAD, the Classification System panel provides direct IFC classification assignment. The key discipline is consistency: all authoring parties must use the same classification system, mapped at the same classification level (for example, all parties mapping to Uniclass 2015 Table En "Elements" rather than some using Table Pr "Products").
Layer mapping — relevant when importing IFC back into 2D drafting tools such as AutoCAD — should follow a project-agreed Layer Naming Convention. IFC object types should map to recognisable layer names so that the receiving draughtsman can immediately locate wall, door, and structural elements without manual sorting.
Step-by-Step Implementation: Establishing a Reliable IFC Exchange Protocol
The following workflow applies to any project where two or more BIM authoring tools exchange IFC files.
Step 1 — Define the exchange at BEP stage. Before any modelling begins, the BIM Execution Plan should specify: IFC version (IFC2x3 or IFC4), MVD, classification system, required Psets per element type, and unit standards. This information is the contract between authoring parties.
Step 2 — Create and distribute export templates. Each authoring team creates a named IFC Export Configuration in their tool (Revit .ifcexportcfg, ArchiCAD export profile, Tekla export filter set) that implements the BEP requirements. These templates are committed to the Common Data Environment (CDE) as controlled documents.
Step 3 — Run a first-export validation within the first two weeks of modelling. Export a small representative portion of the model — a single storey or a single discipline zone — and import it into Solibri Model Checker or BIMcollab Zoom. Verify that: spatial hierarchy is intact (IfcSite > IfcBuilding > IfcBuildingStorey > IfcSpace), required Psets are present and populated, classification references are correct, and geometry scale is accurate.
Step 4 — Conduct a formal round-trip test. Export from Tool A, import into Tool B, re-export from Tool B back into IFC, and compare the two IFC files using a schema-aware diff tool such as the IFC Diff utility in Solibri or a custom Python script using ifcopenshell. Document any data that degrades in transit; raise these as BIM Issues in the CDE.
Step 5 — Automate and schedule. Once a stable export configuration is validated, schedule recurring automated exports — typically weekly or per milestone — using Revit's Dynamo scripting environment, ArchiCAD's GDL Publisher, or a CI/CD pipeline built on ifcopenshell in Python. Automated exports eliminate the human-error risk of a team member using a personal export configuration rather than the project template.
Step 6 — Validate on receipt, not just on export. The receiving party is equally responsible for validating imports. Run every received IFC through a model checker against the project's Information Delivery Specification (IDS) before using the data for coordination or quantity take-off.
Real-World Case Studies
Mixed-Discipline Hospital Coordination, London
On a 450-bed hospital project in London, the architectural team authored in Revit while the structural engineers used Tekla Structures and the MEP consultants used MagiCAD. Early coordination meetings revealed that structural IFC exports were arriving in Navisworks without any fire-rating property data, and MEP exports were losing system classification — making it impossible to distinguish chilled water pipework from domestic cold water by colour-coding.
The root cause in both cases was default export configurations. Tekla's default IFC export does not include Pset_BeamCommon unless explicitly enabled. MagiCAD's system classification lives in a custom Pset (MagiCAD_PipeSystemCommon) that Navisworks does not recognise unless a custom Appearance Profiler rule is added on the import side.
Resolution took three days of configuration work: updated export templates were distributed via the CDE, a validation checklist was added to the weekly BIM coordination meeting agenda, and an automated weekly export pipeline was set up using Dynamo scripts. Subsequent coordination rounds ran without data loss.
Residential Tower, Dubai — IFC4 Design Transfer View Migration
A developer in Dubai mandated IFC4 Design Transfer View for all model exchanges on a 55-storey residential tower, partly to align with the Dubai Municipality BIM requirements and partly to enable downstream Energy Analysis in DesignBuilder. The project faced an early crisis when the curtain wall consultant, working in Rhino with VisualARQ, found that their parametric panel system exported as thousands of generic proxy elements rather than as IfcCurtainWall entities.
The fix required a combination of approaches: explicit IFC entity type assignments in VisualARQ's object properties, a post-processing step using ifcopenshell to reclassify remaining proxies, and an agreed data drop schedule that gave the energy consultant a clean IFC at each RIBA stage rather than ad hoc. The post-processing script ran in under four minutes on the full model and was version-controlled in the project's Git repository.
Tools and Software for IFC Quality Assurance
Beyond the authoring tools themselves, a set of specialist utilities makes IFC exchange significantly more reliable.
Solibri Model Checker remains the industry standard for rule-based IFC validation. Its Information Delivery Specification (IDS) checker — introduced in version 9.13 — allows project teams to define machine-readable requirements for which Psets, properties, and classifications must be present on which element types, and to run those checks automatically against every incoming IFC.
BIMcollab Zoom offers a lighter-weight IFC viewer with BCF issue management integration. It is particularly useful for sub-consultants who need to review and mark up IFC models without a full authoring tool licence.
ifcopenshell (Python library) is the open-source backbone of an increasing number of IFC automation pipelines. Common uses include batch Pset extraction for quantity surveying, automated classification assignment, schema validation, and IFC diff analysis. The ifcopenshell.util.element module provides clean APIs for reading and writing Psets without the verbosity of raw IFC STEP manipulation.
Navisworks Manage supports IFC import with configurable object property mapping. Its Clash Detective and Timeliner modules are most effective when received IFC files carry correct object types and classifications — reinforcing why upstream export quality directly determines downstream coordination value.
Trimble Connect and Autodesk Construction Cloud (ACC) both offer cloud-based IFC federation and basic property checking, and are increasingly used as CDE platforms on large infrastructure projects. Both platforms apply their own IFC parsing logic, so an IFC that validates correctly in Solibri may still render unexpectedly in ACC — worth verifying at project start.
Metrics: Measuring the Value of a Well-Configured IFC Exchange
The business case for investing in IFC export configuration is quantifiable. Teams that instrument their BIM processes consistently report:
- Clash detection efficiency — projects with correctly classified IFC models resolve 30–50% more clashes per coordination session because element filters and colour-coding work reliably. Coordinators spend less time diagnosing "what is this element?" and more time resolving actual design conflicts.
- Quantity take-off accuracy — quantity surveyors working from properly populated IFC Psets report take-off times reduced by 40–60% compared to working from geometry-only exports. The time saving on a mid-size commercial building (say, 15,000 m² GIA) easily exceeds 80–100 hours of QS labour per stage.
- Facilities management handover — projects delivering COBie-compliant IFC handover packages reduce asset data entry at handover by an average of 70%, according to UK Government BIM Level 2 case studies. On a large public-sector estate, this translates directly into reduced FM consultant fees and faster population of the CAFM system.
- Rework from coordination errors — the RIBA and Dodge Data & Analytics research consistently places coordination-failure rework at 5–15% of project cost on traditionally documented projects. BIM projects with reliable IFC exchange protocols reduce that figure; the IFC configuration investment is a fraction of a single rework event.
Troubleshooting Common IFC Export Issues
Even with meticulous configuration, issues arise. The following are the most frequently encountered problems and their resolutions.
Misalignment of model coordinates. The most common cause is the authoring tool exporting from its internal origin rather than the project's shared coordinates. In Revit, ensure the IFC export is set to "Shared Coordinates" rather than "Internal Origin." In ArchiCAD, verify the Project Origin is set to the agreed project Survey Point. On large sites, a misalignment of even a few millimetres at export compounds into visible clashes at coordination.
Loss of Psets on import. If Psets are present in the IFC file (verifiable by opening the STEP file in a text editor and searching for IFCPROPERTYSET) but not visible in the destination tool, the issue is typically the destination tool's Pset import filter. Navisworks, for example, requires custom Pset tabs to be configured in the File Options > IFC panel. Solibri displays all Psets by default, making it a useful diagnostic tool when other applications appear to lose data.
Textures and material appearances not transferred. IFC carries material names and layer thicknesses via IfcMaterial and IfcMaterialLayerSetUsage, but visual appearance (colour, texture maps) is handled separately via IfcSurfaceStyle. Many tools export geometry without surface styles. This is generally acceptable for coordination and data workflows but requires post-processing for visualisation. If appearance fidelity is required, supplement IFC with a parallel FBX or OBJ export for the visualisation team.
Spatial hierarchy breaks. Elements appearing at the project root rather than assigned to a storey indicate that the authoring model's spatial hierarchy was not correctly populated before export. In Revit, all elements should be hosted to a Level; in ArchiCAD, all elements should be assigned to a Story. Unassigned elements export as IfcBuildingElementProxy directly under IfcBuilding, which breaks storey-based filtering in coordination tools.
File size causing performance issues. An IFC file that is unexpectedly large (over 500 MB for a single discipline) typically indicates redundant geometry — duplicate elements, unexploded in-place families in Revit, or nested symbols in ArchiCAD. Running a model audit before export is more effective than attempting to compress post-export. ifcopenshell's remove_unused_representations utility can reduce file size by 20–40% without data loss.
Conclusion
Mastering IFC export settings is not merely a technical requirement — it is a foundational investment in the reliability of every downstream decision made on a project. A well-configured IFC exchange protocol, documented in the BEP, validated at project start, and automated where possible, pays dividends in coordination efficiency, quantity accuracy, and handover quality that dwarf the time cost of the configuration work itself. The discipline of round-trip testing, template management, and receiving-side validation transforms IFC from a format that "mostly works" into a genuinely trustworthy data carrier.
Adyantrix brings deep, hands-on expertise to exactly this challenge. From authoring bespoke IFC Export Configuration templates and IDS validation rulesets for complex multi-discipline projects, to building automated ifcopenshell pipelines that enforce data quality at every exchange milestone, our team ensures that the BIM data your project generates arrives at its destination intact and actionable. Whether you are migrating a legacy project to IFC4, troubleshooting a problematic exchange between incompatible tools, or establishing an open BIM protocol for a new framework contract, Adyantrix can provide the technical rigour and practical experience your programme requires.
Speak with our BIM Consulting team at Adyantrix to find out how we can support your next project.
