Revit or IFC: choosing the right delivery
Choosing between Revit and IFC is a workflow decision. A native Revit file can support continued work in the agreed Revit environment, while IFC supports information exchange across compatible applications. Some projects need both. The right brief begins with the next users and their tasks, then defines the files that let them work effectively.
Describe what happens after delivery
List who will edit, who will review and who will only view the model. If the practice plans to continue authoring in Revit, agree the required version and office standards before modeling begins. If consultants need an exchange model, ask about their receiving environment and information requirements. Avoid treating a request for a file format as a complete specification. The content, naming, level structure and associated notes still determine whether the delivered file is useful.
Agree two different acceptance checks
For a native file, review its organization as well as its visible geometry. Can the practice identify levels, understand component names and continue the agreed architectural work? For IFC, inspect the exported result in the intended viewer or receiving application. Check that the necessary elements and properties are present and understandable. These checks address different uses, so one cannot replace the other. Record limitations clearly rather than assuming both files behave identically because they show the same building.
Keep paired deliveries synchronized
When both formats are supplied, give them matching issue references and dates. State which native revision produced the IFC and retain earlier issues in an archive. If a correction changes geometry or information, confirm whether both files need reissuing. A reviewer should not have to infer the current package from file modification dates. Include a concise issue note with the source references, unresolved questions and any agreed exclusions, especially where architectural and engineering responsibilities meet.
Choose files from user needs
- List each recipient, their application and whether they must edit, exchange or only view the delivered architectural information at this stage.
- Confirm the native version requirement separately from the IFC exchange requirements, then test unfamiliar receiving arrangements using a small representative package.
- Keep paired files on matching issue references and state when a revision changes one deliverable or requires a coordinated reissue of both.
Ask for the simplest package that supports the next stage without closing off required editing or collaboration. Test an example early when a receiving team's requirements are unfamiliar. A well-chosen delivery combines suitable formats with clear information and an agreed review process. Requesting every possible file is less useful than confirming that the people receiving the work can actually use it.
Sources and technical reading
General guidance: each project's scope is confirmed before commissioning.