What Should Architects Verify in an IFC 4 Conversion Checklist in 2026?

What Is an IFC 4 Conversion Checklist?

An IFC 4 conversion checklist is a structured quality-control process for testing whether an architectural model exported to Industry Foundation Classes 4 has preserved the information needed by downstream applications. It should verify geometry, spatial organization, classifications, properties, relationships, units, and file integrity rather than merely confirming that software can open the model. IFC is an interchange standard, not a guarantee that two applications will interpret every object identically. The conversion is successful only when the intended recipient can retrieve the expected rooms, walls, openings, storeys, quantities, and metadata within agreed tolerances. For architectural drawing-to-code workflows, teams should define the receiving jurisdiction, output format, model scope, and authority criteria before conversion begins. As of 1 October 2026, buildingSMART’s IFC4 documentation and the relevant national BIMsubmission requirements should form the technical baseline.

Also worth reading: How Should Architects Test DWG Interoperability Before Automating Drawing-to-Code Conversion? · Can Automated Architectural Code Conversion Turn Drawings Into Buildable Code? · Can native BIM compliance automation transform how architects meet building codes?

The checklist also needs an acceptance owner. The model author, BIM manager, architect, code reviewer, and software specialist may judge the same defect differently, so responsibility must be assigned in writing. A practical acceptance threshold might allow no missing fire-rated walls, no unclassified exterior doors, and no duplicated spaces in the rooms schedule, while allowing visual deviations below 1 millimetre on a nominal 100-millimetre partition. Those figures are project examples, not universal IFC rules. The best checklist is therefore a contract between the authoring team and the receiving process, supported by repeatable model-view definitions, query sets, and comparison reports.

How to Prepare the Source Model Before Conversion

Preparation determines whether conversion problems can be diagnosed or merely discovered later. Begin with a clean architectural model containing only relevant objects, unless federation is explicitly required. Remove abandoned entities, duplicate layers, unused resources, and temporary construction or annotation objects that have no purpose in the exchange file. Check that storeys have a coherent hierarchy, spaces sit within the correct building storey, and building elements reference suitable materials or types. It is often better to fix these relationships in the authoring environment than to repair them in the receiving application.

Establish tolerances and content rules before exporting. For example, require wall centreline or face geometry accuracy within 5 millimetres, room names populated for at least 98% of occupied spaces, and all external openings assigned to a building or storey. These thresholds must be adjusted to the conversion method: analytical reconstruction from drawings, native BIM export, and scan-derived geometry have different capabilities and failure modes. Keep the source file, export settings, converter version, parameter file, and reference drawings together under a controlled revision. A conversion dated 12 June 2026 should not be confused with a later design revision dated 29 September 2026.

Units and coordinate systems deserve explicit verification. Confirm that lengths are exported in metres, angles in radians or degrees according to the selected schema convention, and project coordinates use the declared coordinate reference system where geographic placement matters. Native exporter defaults are usually safer than manually entered export settings, but they still require testing. Run a small pilot model containing walls with openings, curtain walls, stairs, ramps, room boundaries, classifications, and custom properties. Do not use a production model as the first test, because an unnoticed mapping error can affect thousands of elements.

Validate Geometry, Spaces, and Building Structure

Geometry validation should test whether the converted model can support the intended architectural and code checks, not whether it merely resembles the source visually. Use an independent IFC viewer and, where possible, a second application to inspect solids, surfaces, openings, axis data, and Boolean results. Open several enlarged and reduced views because missing geometry may remain hidden at the initial zoom level. Compare storey heights, wall locations, window and door extents, stair runs, and room boundaries against the source model or dimensioned drawings. Record every deviation by IFC GUID, source object identifier, storey, category, measured difference, and disposition.

Spatial integrity requires more than closed room boundaries. Every relevant IfcSpace should have a unique identifier, suitable name, usable area or volume where required, and a valid containment relationship to a storey or another space. Check for spaces merged across walls, spaces assigned to the wrong level, and rooms whose boundaries include wall faces or openings incorrectly. For code workflows, verify that circulation, accessible routes, shafts, exterior zones, and fire-safety spaces have been represented according to the receiving profile. IFC4 itself does not determine whether a building complies; it transports asserted information that still needs project-specific review.

Non-geometric structure also affects measurement. Confirm that spaces are not double-counted through overlapping aggregations, that storey elevations match project datum rules, and that quantity schedules do not include objects excluded by the agreed scope. A useful pilot acceptance target is 100% traceability for rooms and rated assemblies, 98% completeness for required door attributes, and zero unexplained duplicates in the main quantity schedules. These percentages are managerial thresholds rather than buildingSMART mandates. Once the pilot passes, automate the same queries across the production model and retain the reports as conversion evidence.

Check Properties, Classifications, and Relationships

IFC conversion often appears successful because geometry is present while semantic information is incomplete. For every required property set, compare source values with imported values in the receiving platform. Typical fields include wall function, door operation, glazing performance, room occupancy, gross or net area, fire rating, acoustic rating, thermal performance, and accessibility status. Confirm that property names, data types, units, enumerations, and null values are preserved. A fire rating entered as text in one system may arrive as a generic label rather than a classified object, which can look acceptable on screen but fail a code-rule query.

Classifications require separate review. Check that the correct classification system and edition were selected, that entities reference the intended concepts, and that fallback or undefined classes are not hiding incomplete mapping. If a national BIMsubmission guide prescribes classification, naming, or property rules, it takes precedence over generic software preferences. Custom project properties should be placed in documented property sets with stable names rather than copied into unrelated fields for convenience. Preserve source identifiers so every important result can be traced back to the architectural object or drawing component that produced it.

Relationships are easy to lose because many viewers do not display them prominently. Validate containment, decomposition, connection, space boundaries, opening voids, material associations, and type-object links. Test that doors fill wall openings rather than being modelled independently from them, and that room boundaries reference the correct adjacent elements. Run cycle or dependency checks where the recipient supports them, but do not treat absence of reported errors as proof of semantic correctness. Maintain a mapping register with at least one confirmed example for each relationship type, for example exterior wall to building, slab to storey, window to opening, and room to level.

Compare Native Export, Automated Conversion, and Manual Review

There is no universally superior IFC conversion route. Native export from BIM authoring software usually preserves author-defined objects and relationships well, but it can expose proprietary assumptions or omit third-party content. Automated drawing-to-code conversion can create a reviewable model from drawings more quickly than manual reconstruction, especially for repetitive geometry, yet it still depends on legible inputs, reliable layers, and a defined code template. Manual modelling offers direct control but consumes substantially more labour. Hybrid conversion is often strongest: automate repeatable extraction, validate geometry automatically, and assign a specialist to ambiguous spaces, fire compartments, and unusual assemblies.

Cost should be evaluated per accepted model rather than by licence price alone. As a planning example, a five-person review team spending eight hours per model incurs 40 person-hours before engineering corrections; at a blended internal rate of $75 per hour, direct review labour is $3,000. Automated services may reduce reconstruction time but still require setup, drawing review, exceptions, and downstream correction. Quotes vary by project size, input quality, output scope, template count, integration requirements, and support level, so public dollar comparisons are rarely meaningful. Obtain a written estimate that states whether fees are per model, per drawing sheet, per square metre, or subscription-based.

Test Interoperability in Independent Applications

An IFC file should be tested in software outside the environment that created it. At minimum, open the file in the intended receiving platform and one independent viewer; for code or quantity workflows, test the analytical application as well. Record application name, version, build number, date, operator, model-view definition, and selected import settings. Confirm that geometry, colours, names, classifications, property sets, relationships, and schedules survive each transfer. Screen images are useful evidence, but structured export reports and saved IFC query results are easier to compare across revisions.

Avoid declaring success merely because the target application opens the file. Some importers silently flatten spaces, convert solids to generic components, skip custom properties, or assign local coordinates without preserving project location. Test object selection and data retrieval, not only display. Rebuild a small quantity schedule in the recipient system and reconcile it with the source or approved drawing schedule. For a pilot with 100 rooms, 100% should appear before approval if every room is in scope; for a drawing set containing 1,000 room labels with an agreed 20-label exception budget, document which labels were omitted and why.

File packaging should be reviewed before delivery. Confirm that referenced resources such as textures, fonts, property sets, and libraries are either embedded or supplied under agreed rules. Use a meaningful filename containing project, revision, discipline, and date without exposing personal information. Keep the IFC, validation report, model-view definition, mapping file, source register, and exception log together. Archive the test file used for approval so a later recipient can reproduce the result rather than assuming that the same converter settings will still work after a software update.

Common IFC 4 Conversion Mistakes

The most damaging mistake is treating conversion as file creation rather than acceptance testing. A completed export proves only that a file was produced. Teams also make the mistake of validating only the model they authored, overlooking recipient-specific import profiles. Another common error is accepting room polygons without checking whether they represent net, gross, or construction-area conventions consistently. Property units are frequently wrong, especially where area is confused with volume or percentages are exported without a reference quantity.

Version confusion causes avoidable failures. A schema label in a filename does not prove that the file is valid IFC4; validators should report the declared schema and relevant conformance rules. Similarly, “IFC compliant” is not a precise acceptance statement because exporters and importers may support different entity combinations. Teams should document the exchange requirements instead of relying on broad claims. Date and revision control are equally important: rebuilding a model without changing the approved geometry can still alter GUID associations, property ordering, coordinates, or classification references.

Automated conversion introduces its own risks. Drawing layers may not correspond consistently to model categories, duplicated linework may create overlapping walls, and dimensions may be interpreted at the wrong scale. Set a rule that each significant object must have one authoritative source representation, and route duplicates to an exception queue. Review at least 5% of drawings plus every high-risk area during initial calibration, increasing coverage to 10–20% when disagreement rates exceed 2% or when missing or duplicate categories appear. These are sample governance thresholds, not universal standards; final sampling should reflect risk and project size.

When to Convert, Reconvert, or Escalate

Convert early enough to expose data or geometry problems while changes remain inexpensive. A representative pilot should normally occur before the design is frozen, with formal production validation after the last coordinated architectural revision. Teams working to a public authority submission should obtain the authority’s current BIMsubmission guide, accepted schema version, file-size rules, naming conventions, and coordinate requirements. Requirements can differ by authority and jurisdiction, so a generic IFC4 checklist is only the technical starting point. For a jurisdiction using IFC2X3 or another exchange profile, forcing IFC4 may add mapping work without improving acceptance.

Escalate immediately when a defect affects life-safety boundaries, accessible routes, fire compartments, room totals, or gross-versus-net area. Also escalate if conversion creates unresolvable overlapping solids, loss of type identity, systematic scale errors, or changes in more than 5% of critical elements. A 2% discrepancy in 1,000 repeated objects means 20 potentially incorrect instances and may justify a larger review. If one missed entity could alter compliance or cost, statistical sampling is insufficient; inspect that entity and its adjacent context directly.

Reconversion is appropriate after changes to drawing scale, geometry engine, export template, coordinate origin, classification library, or schema settings. It is not necessary solely because a file was renamed or archived. Record the converter and receiving-software versions so a rebuild can be reproduced or deliberately superseded. On 1 October 2026, the project team should use current documentation from buildingSMART, the relevant authority, and each participating vendor because software validation and submission profiles change over time.

Who Owns Acceptance and What Does It Cost?

Acceptance should be owned jointly by the model author and the downstream user, with a named project authority resolving disagreements. The author is responsible for demonstrating that source geometry and mappings were complete; the recipient is responsible for confirming that its platform interprets the agreed exchange content correctly. Code compliance remains the responsibility of qualified project professionals, while the converter may automate extraction and consistency checks without accepting legal or regulatory responsibility.

Budget for preparation, calibration, validation, exception handling, and rework—not just the converter subscription. Small pilot models may cost less than a full day of technical review, while production programs can require recurring data management and model-auditing effort. Where vendors quote per model or per seat, ask about drawing revisions, additional levels, custom property sets, API calls, storage, and support. On automated architectural drawing-to-code platforms, evaluate whether the output includes traceable evidence linking converted entities to source sheets, because visual speed has limited value if reviewers cannot understand corrections. The lowest-cost approach is the one that reduces total accepted-model cost without bypassing review.

A defensible final decision requires a 100% check of required pilot categories, documented tolerances, an exception register, and approval from both producing and receiving teams. Production files should pass the same automated queries, independent-application tests, and schedule reconciliation used in the pilot. If any critical defect remains open, label the file “work in progress” or “not for submission” rather than “IFC4 compliant.” This language is simple but prevents a technically valid file from being mistaken for a code-compliant or fully approved model.