INQ: Issue in "Export As IFC Entity"

[HeHa83]

Inquiry description

Hello,

in Revit 2026, the “Export As IFC Entity” interface does not correctly preserve the spelling of all PredefinedTypes under the IfcEntity “IfcFootingType”.
As you can see, it should remain written as a single word, but it is separated by an underscore during the export.
This leads to errors when these values are validated.

Is the same in Revit 2024...

Revit Version

2026.4.x

IFC for Revit Addon Version

26.4.1

Windows Version

11 25H2

[ArtemHnatko]

Hi @HeHa83,

Thank you for the report and the screenshot.

Conclusion
The exporter writes IfcFootingType predefined types using the uppercase, underscore-separated literals defined for IfcFootingTypeEnum in the IFC specification (for example STRIP_FOOTING, FOOTING_BEAM). That matches the published IFC4.3 definition: IfcFootingTypeEnum — IFC4.3.2. We therefore consider this consistent with the standard, not incorrect export spelling.

Ticket closure
We are closing this ticket because we have not identified a defect in Revit’s IFC export relative to the official schema enumerations. Any validation failure is most likely due to third-party or project-specific rules that do not match the IFC literal set for your chosen schema. Adjusting those rules—or the exchange agreement—is outside the scope of a product bug report for the behavior described.

Thanks again for reaching out.

[HeHa83]

Hello,

that’s correct regarding the terminology, but why aren’t the types in the interface displayed with an underscore separating them? I’ve used all the types in a translation table to help my colleagues. If the text list in the interface doesn’t actually comply 100% with the IFC 4.3 standard, it can be very confusing for someone who isn’t familiar with it.

[ArtemHnatko]

Hi @HeHa83,

Thanks for the clarification — that’s a very fair point.

You are correct that the values shown in the Revit UI do not exactly match the IFC enumeration format. The UI is designed to present these types in a more human-readable form (e.g., “PADFOOTING”), while the exporter converts them to the IFC-compliant format (e.g., “PAD_FOOTING”) during export.

We agree that this difference can be confusing, especially when creating translation tables or working closely with IFC schema definitions.

At the moment, this behavior is by design, but your feedback is valid. Aligning the UI display more closely with the IFC standard (or providing clearer mapping) could improve usability and reduce ambiguity.

We will log this as a usability improvement for consideration.

Thanks again for highlighting this.

[ArtemHnatko]

This issue is also reported in Jira as "REVIT-249668" and is currently in the "Open" status.