The files land the same way on every project. One IFC from the architect, one from the constructeur, one from the installateur, each drawn in a different program. You open them, and half the time they do not line up, or a wall turns out to be a nameless block with nothing behind it. The reflex is to blame the viewer. Usually it is the export. Here is what a clean IFC carries, whichever tool made it, and how the three end up in one model.
The tool matters less than the settings. That is the part most people skip.
The export decides everything
Revit, Archicad and Tekla each draw in their own native format, and each exports to IFC. That export is a translation, and like any translation it can be done with care or in a hurry. The same building can leave one office as a rich, queryable IFC and leave another as a geometric shell that looks right and answers nothing. The program did not change. The settings did.
So the first move is not to hunt for a better tool. It is to agree, before anyone exports, what the IFC has to contain.
Three things a clean export carries
Objects that know what they are. A wall should export as an IfcWall, a door as an IfcDoor, a beam as an IfcBeam. When the mapping is wrong or missing, everything falls back to a generic IfcBuildingElementProxy: a shape with no type. A proxy is a block you cannot filter, cannot count, and cannot hang a rule on. Getting the object mapping right is most of the job.
The data, not just the shape. The worth of a model is in its property sets and its base quantities: the fire rating, the U-value, the material, the area and the volume. A model exported without them is a picture. Bring the property sets along, and every element can answer a question.
One shared origin. Three files only line up if they agree where the building sits. Set a shared coordinate system, or a common project base point, before export. Skip it and the structure floats a hundred metres from the architecture, and no viewer can guess the offset for you.
Pick a schema, and say which one
IFC comes in versions. IFC2x3 is the old workhorse, still everywhere. IFC4 is richer and now the common choice. IFC 4.3, ratified by ISO as ISO 16739-1:2024, widened the format to infrastructure. Any of them can carry a good building model. What causes grief is not knowing which one you were handed, so name the schema in your export agreement and keep it consistent across disciplines. Most tools also let you export a defined view, the coordination view, shaped for exactly this: handing a model to someone else to combine.
Where imports go wrong
Most import trouble traces back to one of a handful of export habits.
The usual suspects
- Everything arrives as a proxy, because the object types were never mapped.
- Elements are present but empty, because the property sets were left out.
- Volumes read a thousand times too big or too small, because one model was in millimetres and another in metres.
- The disciplines do not overlap, because nobody set a shared origin.
None of these are viewer bugs. They are decisions made at export, which means they are fixable at export, once you know to look.
Many tools, one scene
Here is the point of doing it right. Because IFC belongs to no single vendor, and a neutral body, buildingSMART, looks after the standard, a model from one program opens cleanly in another. Get the exports clean and the architect's model, the constructeur's model and the installateur's model line up in one federated scene, where you can see the duct running through the beam before the concrete is poured. That is not a Dutch trick. It is the same open standard from Rotterdam to anywhere in Europe the format reaches.
Clean data pays off later
The cleaner the IFC, the more you can do with it downstream. A finding pins to a real element instead of a vague note. A compliance rule has properties to read instead of blanks. The work you put into the export comes back every time someone questions the model.
Where we come in
That federated model is where BimDossier starts. It reads standard IFC, including the compressed .ifcZIP, detects the schema on upload, and loads models from every discipline into one viewer scene with storey isolation and section planes. Pin a finding to an element and it hangs off that element's own identifier, with a photo and an owner. The compliance engine runs its rule packs against the same IFC data.
What it does not do is author the model. That still happens in Revit, Archicad or Tekla, and a thin export is still a thin export. Get the IFC clean on the way out, and everything you build on top of it, the snags, the certificates, the Wkb dossier, sits on a model that can answer for itself.