Back to the BIM & IFC blog
Tools & comparisons · 2026-10-01 · 11 min
How to Compare Two IFC Versions and See Exactly What Changed
"What changed since last week?" is the question every coordinator asks and almost no IFC tool answers well. Comparing by GlobalId across a whole set of files — not one file against one file — is what turns a diff into a weekly review.
How to Compare Two IFC Versions and See Exactly What Changed — IFC Viewer Online article cover
Every Monday, somewhere, a BIM coordinator receives a new drop of discipline models and asks the only question that matters: what changed? The honest answer on most projects is "we open both and look". That works for a house. It does not work for eleven files and forty thousand elements.
Comparing IFC versions properly is not hard, but it rests on one decision that most tools get subtly wrong: what counts as "the same element".
Identity is the whole problem
Matching by GlobalId across the whole set: a changed property, an element that moved between discipline files, an addition and a removal.
An IFC element has two identifiers. The express ID (the #1234 in the file) is a line number — it is renumbered on every export and means nothing across versions. The GlobalId is a 22-character GUID designed to persist for the life of the element. A comparison that matches by anything other than GlobalId is comparing line numbers.
Stable GUIDs are an export setting, not a modelling task — why IFC GUIDs change on every export covers the fix for each authoring tool. And if you have the opposite problem, the same GUID used twice in one file, see duplicate GUIDs in IFC.
Compare the set, not the file
Real projects are federated: architecture, structure, MEP, sometimes split further by building or level. Comparing file against file misses the most interesting change there is — an element that moved between files. The structural engineer takes ownership of a wall the architect modelled; a file-by-file diff reports one deletion and one unrelated addition, and both of them are wrong.
Matching by GlobalId across the whole set fixes that. The element is found in both versions, its file differs, and it is reported once, as modified, with the reason "moved to another file". File-level matching still has a job — the per-file summary — but it is a presentation detail, not the identity rule.
What "modified" should mean
A useful comparison says not just that an element changed but how. These are the categories worth separating, because each one goes to a different person:
| Change | Example | Who cares |
|---|
| Added / removed | A new partition; a deleted column | Everyone — this is the headline |
| Class changed | A proxy became an IfcWall | Coordinator, quantity surveyor |
| Attributes | Name or tag edited | Whoever owns the schedules |
| Properties | FireRating went from EI 60 to EI 30 | Fire engineer, specifier |
| Classification | Uniclass code changed | Cost and FM teams |
| Material | Concrete grade changed | Structural engineer |
| Containment | Moved to another storey | Coordinator |
| File | Moved to another discipline model | Information manager |
A diff that only says "changed" is a list of places to go and look. A diff that says what changed is a review you have already done.
The weekly review, in five steps
- Load the new drop All the files of the set, as one scene. Parsing happens in the browser, so confidential models stay on your machine.
- Compare against the previous version or a saved baseline A baseline is a snapshot you keep locally — last week's accepted state, or the one tied to a payment milestone — so you do not need the old files open to compare against them.
- Read the summary, then the 3D Added in one colour, modified in another, removed in a third. The per-file summary tells you which discipline moved; the colours tell you where.
- Re-run the IDS on both versions The same specification evaluated on the old and new model shows which requirements were fixed and which regressed — without parsing either file again.
- Update the BCF Changes that need action become topics labelled with the version they came from, so next week's comparison does not raise them twice.
Step 4 is where a comparison stops being a curiosity and becomes quality control. Setting up the specification in the first place is covered in IDS explained; step 5 in BCF 2.1 vs 3.0.
Reading a comparison without being misled
- A large number of property changes with no geometry changes usually means an export setting changed, not the design. Check the export template before you check the modeller.
- Removed plus added in similar counts on the same class is GUID churn, not redesign. Treat it as an export defect.
- Containment changes on a whole storey usually mean the storey was recreated. The elements did not move; their parent did.
- Zero changes is a result worth confirming. Compare the baseline against itself once — it should report exactly nothing — so you know an empty diff is real.
A comparison is also the fastest way to decide whether a new revision is even worth reviewing in full. If it is, how to check an IFC model before delivery is the full routine.
How to Compare Two IFC Versions and See Exactly What Changed