Back to the BIM & IFC blog
Validation · 2026-05-05 · 8 min
The 7 Most Common IFC Validation Errors (and How to Fix Them)
Duplicate GUIDs, orphan elements, and broken spatial hierarchies account for over 80% of IFC delivery rejections. Here's how to spot and fix each one before the model reaches the CDE.
The 7 Most Common IFC Validation Errors (and How to Fix Them) — IFC Viewer Online article cover
Every BIM coordinator has been there: you export an IFC file, send it to the Common Data Environment, and it gets rejected because of structural errors you didn't know existed. After running validation on thousands of IFC files, the same seven errors account for the vast majority of failed deliveries.
- 44 — rules checked
- 7 — cause 80% of rejections
- 30s — to validate any model
- 100% — runs in your browser
1. Duplicate GlobalIds (GUIDs)
A GlobalId is the permanent identity of an IFC element — it survives model merges, version updates, and software migrations. When two elements share the same GUID, every tool that relies on stable references (BCF workflows, Revit link tracking, CDE versioning) breaks silently.
2. Orphan Elements
An orphan is a physical element with no spatial container in the IFC hierarchy — it exists in the file but doesn't appear in Project → Site → Building → Storey. Most viewers skip orphans entirely. The cause is usually elements placed on a level without being associated with a floor plan, or linked-file elements that lost their host storey on export.
3. Wrong Container
The element has a container, but it's the wrong one — placed directly inside IfcSite instead of inside a storey. Site-level placement is valid only for infrastructure elements. Walls or columns inside IfcSite will confuse every downstream tool from Navisworks to Solibri.
4. Broken Aggregates
IfcRelAggregates is the relationship that builds the spatial tree. A broken aggregate means one of these relationships points to a non-existent entity — typically because the entity was deleted after the relationship was written, or during a model merge that didn't propagate deletions correctly.
5. Spatial Hierarchy Violations
IFC mandates a strict order: IfcProject → IfcSite → IfcBuilding → IfcBuildingStorey → physical elements. When this order is broken — a Building directly under Project without a Site, elements placed in IfcBuilding instead of a storey — many tools fail to build the tree correctly.
6. Missing IfcProject
Every valid IFC file must contain exactly one IfcProject. It's the root node of the entire model hierarchy. Some export workflows that generate sub-models omit it. The result is a file that parses without errors but has no spatial root.
7. Empty Element Names
Elements with Name = "" or null aren't a schema violation, but they break nearly every downstream workflow: BCF comments can't reference them clearly, quantity takeoff tables show blank rows, and clash reports become unreadable.
Run a live validation
Open the buildingSMART duplex and see what a clean IFC validation report looks like — then try one of your own models to check for these seven errors.
IFC2x3 · 2.4 MB
Open the interactive IFC viewer
Pre-Delivery Checklist
- Run validation before every CDE upload — not after.
- Target Health Score ≥ 80 for coordination deliveries.
- Zero duplicate GUIDs — non-negotiable for BCF workflows.
- All physical elements inside a storey, not directly under Site or Building.
- One IfcProject at the root — always.
- Name every element, even generically ("Wall-001" beats empty string).
- Spatial hierarchy: Project → Site → Building → Storey → elements.
The 7 Most Common IFC Validation Errors (and How to Fix Them)