It’s one of those questions that drifts through the BIM community from time to time. People ask:
- “Does IFC lose data?”
- “Is data loss problem with IFC getting any better now?”
- “How can we avoid losing information when using IFC?”
But every time I ask the most obvious follow-up:
“Okay... but what kind of data is actually being lost?”
Silence.
No one seems to know. Or, vague answers follow — “this, that, I can't remember the details... but there is something... you know?”
It’s like we’re all haunted by a ghost we’ve never actually seen. So let’s shine a light on it:
Does IFC really lose data? If so, what kind? And more importantly — how can we recognize it, and what can we do about it?
First Things First: Which ‘IFC’ Are We Talking About?
The phrase “IFC loses data” is ambiguous right from the start. Are we referring to the IFC standard or to an IFC file?
- The IFC Standard (Industry Foundation Classes) is an international open standard (ISO 16739) designed to enable interoperability across AEC industry. It defines a neutral, open data schema — essentially a shared language for describing built environment data.
- An IFC File, on the other hand, is a physical file (usually with an extension of
.ifc) that follows the IFC schema. It contains real project data and is generated by software. As long as it conforms to the standard, any tool that supports IFC should be able to open, read, or even edit it.
The IFC standard is the language — not the message itself.
If something gets “lost in translation,” it’s often not the language that’s at fault — but how it's used.
Does the Software Really Understand the IFC Standard?
Software is free to structure and store data in its own way. Depending on its use case and technical architecture, each tool may adopt a different internal data model and follow its own strategy for organizing information.
That’s exactly why we need a shared open data schema, so tools can “translate” their internal data into a common language. To ensure that information can move across different tools and systems.
Think of the software as a translator:
- When exporting: it converts internal data into IFC schema.
- When importing: it interprets IFC data and presents it in its own environment.
How well the software understands the IFC standard directly affects how accurate and meaningful that translation is.
If software maps everything, walls, doors, windows, beams, all into a generic IfcBuiltElement, then technically it may still be a valid IFC file. But semantically? You’ve lost basically everything.
It’s like walking into a massive supermarket where every item is labeled simply as Stuff.
Sure, the products are there — but the information that makes them useful? Gone.
So if there is a software does understand IFC very well and is capable of precise, standard-compliant export.
Would there still be data loss?
Absolutely.
Because at its core, the real issue often isn’t the software — it’s people.
Sender Matters More Than Container
What’s inside a package usually has little to do with the shape of the box, or the logistics system that handles it. It’s mainly up to the sender: what they pack, how much, and how carefully they did it.
An IFC file is just an information container. It doesn’t limit what you put inside. It can carry a lot — properties, geometry, classifications, construction, safety, environmental info... or it can carry nothing — an empty box.
The software takes care of packing and formatting the data correctly, but it's us decide what gets packed.
At the end of the day, we are the ones who decide what information gets exchanged. We choose which data to include, how detailed it should be, and we’re the ones responsible for the quality of the source.
So when information goes missing, it’s not always fair to blame “bad tools” or a “flawed format.” The real answer lies in collaboration between three roles:
- The IFC standard provides a common language, defining how information should be structured.
- Software tools act as translators, determining how well that language is spoken and understood.
- Engineers are the authors and senders, deciding what to say, and how to say it.
So, how can we check and avoid data loss?
Does my software truly understand the IFC standard?
If you want to know whether your software properly supports IFC — whether it can generate a valid IFC file and whether that file conforms to the correct syntax and data structure — there's a simple way to find out:
Use the buildingSMART Validation Service.
This free, open online tool checks whether your uploaded IFC file complies with:
- STEP Syntax
- IFC Schema
- Normative IFC Rules
After the validation, it generates a detailed report. If there are issues, the report will include detailed error messages that help identify exactly what’s wrong.
These reports aren’t just helpful for users to tell if the file is a valid file. They’re also valuable for software vendors and developers, if you find out some issues, by sharing this report with your software vendor making it much easier to troubleshoot and resolve those issues.
Exported IFC file has incorrect types or missing information?
Check whether the export settings are correctly configured. Most BIM software has its own internal type system and usually provides mapping options to align with IFC entities. Make sure your data isn’t being mapped to the wrong type.
For example, if a custom window component is mistakenly mapped to IfcWall, not only the type is incorrect — it may also cause properties to be lost or fail to parse properly.
Understanding how your software handles type mapping and export configurations is essential to ensuring the correct information is been exported.
Can’t find the entity I want in the IFC standard?
Remember, the "F" in IFC stands for Foundation. IFC provides a solid base — but for domain-specific, national-specific or project-specific needs, you can extend it by using data dictionaries, such as bSDD.
And if you believe your additions could benefit the wider industry, feel free to reach out buildingSMART to help shape future versions of the standard.
What if some objects are missing or incorrect in my IFC file?
Start by reviewing your export configurations — make sure all the necessary objects are actually selected for export. Also check whether the source data was filled in correctly at the first place.
To verify the content of your data, you can also use IDS (Information Delivery Specification) to define your information requirements. Many tools now support IDS standard, allowing you to automatically check whether your IFC file meets your information requirements.
Other possible causes
Using pirated software
Using pirated software carries significant risks. If the software wasn't obtained through legal channels, the vendor has no obligation to ensure data integrity or offer support to you. And the consequences of using unlicensed software may go far beyond just losing your data.
Deviation of the IFC standard
Some tools may customize or extend the IFC schema in ways that make the file suit in their own ecosystem, but not in others. It’s like inventing a word that only you understand — naturally, no one else can make sense of it.
Keep in mind: modifying or extending the IFC schema yourself violates the licensing terms of the standard and may involve legal risks.
Standards are standards because we see them the same.
When it doesn’t — that’s art.
Takeaways
- Validate syntax and schema — make sure your IFC file is standards-compliant.
- Review export and mapping settings — ensure the data is semantically accurate.
- Check against information requirements — only meaningful, complete data leads to true data quality.
In the end, your data quality is in your own hands.