What Every IFC File Should Include Before You Trust It

A team decides to work in openBIM. They pick IFC. They agree on a coordination workflow. They write it into the BEP. Looks good on paper.

Then the first model arrives.

Wrong IFC version. Missing property sets. No georeferencing. Storey structure is a mess.

That is not a technical failure. That is an adoption failure. The standards exist. IFC is solid. The tools work. What was missing is that nobody agreed what good looked like before the project started, and nobody checked the file before people started building decisions on it.

I spent 11 years on Norwegian construction and infrastructure projects. On my last one, the new Oslo water supply program, models were production data. The site placed reinforcement directly from model data. If the file was wrong, the site was wrong. You learn to check files very carefully when the consequence of not checking is poured concrete.

So here is what I look at before I trust any IFC file. None of this requires paid software. A free viewer and a few minutes are enough.

1. The right schema version

The most basic check, and still one of the most common failures. The project agreed IFC4, the file arrives as IFC2x3, or the other way around. Everything downstream that depends on version-specific features quietly breaks or silently loses data.

Open the file header and read the version. Ten seconds.

2. Georeferencing

A model with no coordinates, or wrong coordinates, will still open beautifully. It just sits in the wrong place on Earth. The moment someone tries to federate it with another discipline's model, or hand it to a surveyor, the problem surfaces. Usually late, usually expensively.

Check that the file carries the agreed coordinate system and that a known point in the model lands where it should.

3. Storey structure

Elements need to belong to the right storey, and the storeys need to make sense. I have seen files where half the elements hang directly off the building with no storey at all, and files with duplicated or misnamed storeys from a messy export.

Why it matters: quantity takeoff, room schedules, and most filtering and checking workflows group elements by storey. A broken spatial structure makes all of that unreliable.

4. Spaces

Of all the checks, this is the one people skip most.

Missing or broken space boundaries will not stop the file from opening. Everything looks fine. Then someone tries to do quantity takeoff or a room based check and nothing works, and by then the model is already three revisions down the line.

Before anything else, open the file and confirm the spaces are actually there and closed. Thirty seconds. It saves a bad handover.

5. Property sets with real values inside

This is the most dangerous one, so it gets the longest explanation.

The most dangerous IFC file is not the one that fails to open. That one gets caught immediately. The dangerous one is the file where the property sets exist but every value is blank.

You open it. You see Pset_WallCommon on the walls. It looks like the data is there. An automated check that only looks for the presence of the property set passes it. Then someone downstream tries to use the fire ratings, and there is nothing inside.

Empty property sets create the illusion of data. That illusion survives longer than a missing file ever would, and it costs more when it finally breaks.

So do not check for presence. Open real elements and read real values. Presence is not the test. Content is.

6. The elements are what they say they are

On site, we checked installed elements against model properties. A pipe with the right diameter, the right thickness, the right part in the right place. That only works if the model classifies things correctly. A wall exported as a generic proxy, a duct exported as a beam, a slab that is actually three overlapping slabs. The geometry looks right in the viewer. The data underneath is wrong, and every automated workflow that relies on element types fails.

Pick a handful of elements you know. Check what the file says they are.

The real fix sits upstream

Here is the thing I want to leave you with, because the checklist alone does not solve the problem.

Most bad IFC is not a modeling problem. It is a requirements problem. Nobody told the person exporting the file what good looked like, so they guessed.

If you set clear requirements up front, half of these checks pass automatically because the model was built to hit them. That is the whole game. Define good, then check for it. The checking part takes minutes. The defining part is where projects actually win or lose, and it is a skill worth building properly.