Schema conformance
schemaThe file parsed, but something in it does not conform to the IFC schema it declares — an attribute of the wrong type, a missing mandatory value, or an unsupported schema version entirely.
"Deep conformance validation" found an attribute error I don't understand
These come straight from the IFC schema's own validation rules (e.g.
IfcRoot.UR1: GlobalId should be unique), so the wording is standard IFC
terminology, not ClearIFC's own. The finding names the offending entity type and, where
available, the specific element — that is the one to open first.
Most attribute-type errors come from an add-in, plug-in, or an older/newer version of the same authoring tool writing a value the exporter did not expect. If it appears on every export regardless of the model content, suspect the exporter or a plug-in rather than the model.
"No IfcUnitAssignment found" — my model has units, why does this fail?
The model has display units, but no formal IfcUnitAssignment was written
into the export — meaning a receiving system cannot know whether a length value means
millimetres or feet. This is an export setting, not a modelling one.
Check the project units (Manage → Project Units) are set before exporting; the IFC exporter reads them at export time.
Confirm the drawing units match the intended IFC units in the IFC export setup dialog before running the export.
My schema is rejected outright
The template you selected restricts which schemas are accepted (see its definition under Rule templates in the app). If a client's template requires IFC4 and your export is IFC2X3, re-export at the required schema version rather than adjusting the template — the schema is usually specified in the delivery requirements for a reason.
Spatial structure
spatialThe project → site → building → storey hierarchy (or project → facility → facility part for infrastructure) is missing, broken, or elements are not actually contained anywhere in it — meaning nobody downstream can filter your model by level or zone.
"Element is not contained in any spatial structure"
The element exists in the file but was never assigned to a level, storey, or spatial zone during export — common for elements added late, ungrouped, or created outside the normal level-based workflow.
Check the element's Level (or Reference Level for hosted families) is actually set, not blank. An element hosted on another element sometimes inherits a level the exporter does not pick up — try assigning it directly.
Confirm the part sits inside a phase/assembly that is linked to a storey object, not floating in model space unassigned.
Check the element's story assignment in its Settings dialog — elements moved via "Show on Story" tricks can export without a proper containment relationship.
Alignment-hosted infrastructure elements need to sit within an IfcFacilityPart boundary at export — verify the IFC export mapping assigns the object to the correct facility part, not left unmapped.
"No IfcBuildingStorey found" but I definitely modelled levels
Levels usually exist in the authoring tool but are excluded at export time — either the exporter is scoped to a single view/discipline that hides them, or a "levels as reference planes only" setting suppressed writing them as spatial elements.
In the IFC export setup, check Level of Detail and the "Export Levels" option under the Level of Detail/Site tab — some export configurations omit storeys deliberately for coordination-only exports.
Confirm the story is included in the current view/publish set used for the IFC export — a story excluded from the view will not be written even if it exists in the project.
Infrastructure model: "No IfcBuilding found (and no IfcFacility)"
IFC4X3 infrastructure models use IfcFacility/IfcFacilityPart
instead of IfcBuilding/IfcBuildingStorey — ClearIFC accepts
either pattern. If neither is present, the export likely used a building-oriented
template on a non-building asset (a bridge or corridor); check the export uses the
correct IFC4X3 facility mapping rather than a default building template.
Property sets
propertyA required property set is missing, a required property inside it is missing, or the property exists but was exported with no value — which the rule set treats the same as missing.
"Missing property set 'Pset_WallCommon'" (or similar)
Standard Pset_ property sets are usually written automatically by the
exporter from the element's built-in parameters — a missing one almost always means the
underlying parameter was never filled in, not an export bug.
Check the element's Instance Properties for the matching parameter (e.g. Fire Rating, Is External). If it is blank in Revit, it will be blank or absent in the IFC export.
Custom/user-defined attributes need an explicit IFC export mapping in the organizer or the IFC export configuration — a UDA that isn't mapped to a Pset property will simply not appear.
Check the element's Classification and Properties panel; property values come from the assigned Property definitions, not from arbitrary label text on the element.
"Property is present but has no value"
This is different from missing entirely: the property set exists and the property exists, but the field was left blank in the authoring tool. It shows up in the IFC file as an empty value, which is not the same as the property being genuinely absent — and a rule set that requires a value will flag it either way.
The requirement is for a property my tool doesn't have a field for
Not every required property maps to a native parameter. Add a shared parameter (Revit), a user-defined attribute (Tekla), or a custom property definition (ArchiCAD) with the exact name and property set the rule expects, then confirm your IFC export mapping actually carries it across — adding the parameter alone is not enough if the export configuration does not know to map it.
GUID integrity
guidEvery IFC element needs a unique, correctly-formed GlobalId. A duplicate quietly breaks model federation, revision comparison, and any asset register keyed on GUID — it is usually invisible until something downstream silently picks the wrong one.
"GlobalId is shared by 2 entities"
GUIDs are supposed to be generated fresh per element and never reused. A duplicate almost always comes from one of these:
Copying an element between models via clipboard, group insert, or "copy standards" can carry the original GUID with it instead of generating a new one — check whether the duplicated element started life as a copy from elsewhere.
If a coordination tool or federation process re-imports a previous IFC export and merges it back in, elements can end up double-counted with the same GUID. Re-export from the authoring model directly rather than round-tripping through IFC.
An element duplicated across a linked or copy-monitored model, then both instances exported into the same combined IFC, will carry the same GlobalId. Export the federated model once, not each linked model separately into one file.
The fix is almost never to hand-edit the GUID — re-export cleanly from the authoring tool after removing the duplicate element, so a fresh, unique GlobalId is generated.
"GlobalId is not a valid 22-character IFC-compressed GUID"
This means something (usually a script, a data-exchange add-in, or a hand-edited IFC file) wrote a raw UUID or an arbitrary string into the GlobalId field instead of the IFC-compressed base64 form the schema requires. If you are not editing IFC files by hand, this points at a plug-in or middleware step in your pipeline — re-export directly from the authoring tool without that step to confirm.
Geometry
geometryAn element has no geometric representation, an empty one, one the geometry kernel cannot build, or a solid that encloses zero volume — meaning it will not display correctly, or at all, in receiving software.
"Has no geometric representation and will not appear in a viewer"
The element exists as data but carries no 3D geometry. Common causes: the element was created as a schedule-only or symbolic placeholder, its visibility/detail-level setting excluded it from the exported view, or it is a non-visible system element that was swept into the export by mistake.
Check the element is visible in the view being exported and is not set to "Not Shared" or hidden by a view filter — exports typically follow view visibility, not model-wide visibility.
Confirm the part has an actual profile and material assigned, not just a placeholder/reference part with no solid.
"Encloses zero volume" on a solid
The element declares a solid representation but the geometry, once built, has no volume — typically a degenerate profile (zero width or a self-intersecting sketch), or a sweep/extrusion with a zero-length path.
Check for a wall/floor with thickness set to 0, or a profile-based family with a sketch that self-intersects — Revit will often let you create these without warning.
A corridor or feature line with a zero-width assembly segment produces this on export — check the assembly subassembly parameters for the affected segment.
"The geometry kernel could not build it"
This is a genuinely broken solid at the data level — self-intersecting faces, an open (non-manifold) B-rep, or a profile with invalid topology. The finding includes the kernel's own reason where available. These usually trace back to a specific modelling operation (a boolean cut that failed silently, an edited edge that left a gap) on the named element — worth opening that exact element and checking its geometry history in the authoring tool rather than assuming the exporter is at fault.
Classification
classificationAn element has no classification reference at all, or one from the wrong system, or a code that does not match the pattern the rule set requires (a Uniclass table format, for example).
"Has no classification reference"
Classification is a separate assignment from any type or family name — an element can be perfectly named and still carry no formal classification code.
Assign classification via the element's Classification parameters (Uniclass Ss/Pr/etc. fields), or via a shared parameter mapped to classification in the IFC export configuration — a classification only in a text/comments field will not export as a real reference.
Use the built-in Classification Manager to assign a Uniclass (or other) system code to the element or its element type, not a free-text property.
Classification typically needs an explicit UDA-to-IfcClassification mapping in the export configuration; check the mapping includes the code and the system name, not just the code.
Classified, but the code doesn't match the required pattern
The rule set can require a specific code format (e.g. Uniclass Ss_25_10_30_25).
A code from the wrong table, an old edition of the classification, or a free-text
approximation of the real code will all fail the pattern check even though something is
technically assigned. Check the classification was assigned from the actual current
table your client's rule set expects, not a locally-cached older list.
Classified at the type, not visible on the instance — is that a problem?
No — ClearIFC's classification check honours classification inherited from the element's type, matching how most authoring tools actually assign it (once, on the family/type, rather than per instance). If every instance of a type is still failing, check the type itself carries the classification, not each occurrence.