Most published BIM audit checklists are lists of nouns. “Naming conventions.” “Model health.” “Clash detection.” Nobody disagrees with them, and nobody can fail them, because a check without a stated pass criterion is an opinion with a tick box next to it. This guide takes the opposite approach: every check below states what is being verified, what counts as a pass, and what the failure usually looks like on a real project. It is written against ISO 19650 and assumes the audit is measured against a project’s own BEP and EIR — because an audit with no contractual reference point cannot compel anyone to fix anything.
- What a BIM audit actually is
- What the audit is measured against
- When to run one, and how deep
- The BIM audit checklist
- Setting pass / fail criteria
- Running the audit: seven steps
- What the audit report contains
- Tools that automate the checks
- BIM audits on Saudi and UAE projects
- Seven ways a BIM audit fails
- Frequently asked questions
What a BIM Audit Actually Is
A BIM audit is a structured, evidence-based review of whether a model and its supporting information meet the requirements agreed for the project, carried out by someone who did not produce them.
That last clause is what separates it from the three activities it gets confused with.
| Activity | Who does it | When | What it answers |
|---|---|---|---|
| QA — quality assurance | The producing team | Continuously, during modelling | Are we working in a way that prevents defects? |
| QC — quality control | The producing team | At the end of a work package | Does our own output contain defects? |
| Clash detection | BIM coordinator | Every coordination cycle | Do the disciplines physically conflict? |
| BIM audit | An independent reviewer | At defined milestones and exchanges | Does the deliverable meet the stated requirement, and can that be evidenced? |
Clash detection is a subset of an audit, not a synonym for it. A model can be entirely clash-free and still fail an audit on coordinates, classification, naming or data completeness. Our guide to clash detection types and process covers that discipline in its own right; this guide covers the wider review that contains it.
Internal check versus independent audit
ISO 19650-4 formalises the distinction as two gates. The producing team performs its own check before information leaves the work-in-progress state — a named individual, identified in advance, certifying their own output. The receiving party then performs acceptance before that information is published and becomes the contractual record. Both are recorded with a name, a date and a coded outcome; an anonymous or undated acceptance carries no weight in a dispute.
In practice this means two different checklists at different depths, run by different people. Treating them as one exercise — the modeller auditing their own model — is how projects arrive at handover with a full folder of signed sheets and an unusable deliverable.
What the Audit Is Measured Against
An audit needs a reference document. Without one, the auditor is comparing the model to their own habits, and the producing team is entitled to ignore the findings.
| Reference | What it tells the auditor |
|---|---|
| EIR — Exchange Information Requirements | What each appointed party must deliver, in what format, at which milestone |
| BEP — BIM Execution Plan | How the team agreed to work: naming, worksets, classification, software versions, coordinate strategy, tolerances |
| LOIN / LOD schedule | The geometry, data and documentation required per element at this stage |
| MIDP / TIDP | Which containers should exist at this milestone, and who owns each one |
| Applicable standard | ISO 19650 series, plus any authority or client-specific submission requirement |
If any of those are missing, that is itself the first audit finding — and usually the most valuable one. Our guide to the BIM Execution Plan covers what a BEP has to contain to be auditable, and our guide to ISO 19650 and information management covers the framework the whole exercise sits inside.
When to Run One, and How Deep
The most common structural error in BIM auditing is applying the same depth of check at every stage. Full-rigour auditing at concept wastes effort on a model that will be rebuilt; light-touch auditing before handover lets data loss through at the one point where it becomes permanent. ISO 19650-4 requires rigour to be proportionate to the stage, and the level should be set in writing before the first exchange rather than negotiated each time.
| Stage | Depth | Focus of the audit |
|---|---|---|
| Concept / schematic | Light | Coordinates, file and container naming, template compliance, workset structure |
| Developed design | Medium | The above, plus classification coverage, parameter population, cross-discipline consistency, first federation |
| Technical design | Full | Full compliance: LOIN completeness, clash status by severity, documentation against the sheet register, IFC export test |
| Construction | Full | As above, plus verification against site reality and approved substitutions |
| Handover | Full + verification | As-built verification, asset data completeness, tag alignment, FM import test |
Between milestones, a short recurring health check — warnings, file size, links, coordinate integrity — run weekly by the BIM coordinator catches the drift that would otherwise accumulate into a failed milestone audit.
The BIM Audit Checklist
Eight sections. Each check states the pass criterion and the failure it is designed to catch. Thresholds shown are working defaults — the section after this one covers how to set your own.
1. Files, containers and the CDE
| Check | Passes when | Typical failure |
|---|---|---|
| Container naming | Every file matches the agreed convention exactly, field by field, with no manual variants | “Rev C final_2” appended by one team; automated validation never configured |
| Status and revision codes | Every container carries a valid suitability code and a sequential revision | Files published straight from WIP with no status code applied |
| CDE state | Files sit in the correct WIP / Shared / Published / Archive state for their status | The “Shared” folder used as a working drive; nothing ever formally published |
| Superseded content | Only current revisions are live; superseded versions are archived, not deleted | Three versions of the same drawing live simultaneously, none marked current |
| Metadata | Discipline, level, zone, type, status and revision populated on every container | Blank metadata fields accepted at upload |
| Audit trail | Every status change records who, when and on what instruction, and cannot be edited afterwards | Files moved between folders manually with no record |
Our guide to the common data environment covers the state model and permissions structure these checks assume.
2. Model setup and coordinates
| Check | Passes when | Typical failure |
|---|---|---|
| Shared coordinate system | All discipline models open in the same shared coordinate system and align on insertion with no manual offset | Each consultant modelled at internal origin; federation requires a nudge to line up |
| Project base point and survey point | Both are set, documented in the BEP, and unchanged since the last exchange | Base point moved mid-project to suit one team’s view range |
| Distance from internal origin | The model sits within the software’s accuracy envelope of the internal origin (commonly under 10 miles / 16 km) | Model placed at real-world survey coordinates, producing rounding and view errors |
| Levels and grids | Names, elevations and grid references match the architectural reference exactly across all disciplines | Structure calls it “L2”, architecture calls it “Level 02”, MEP has both |
| Units and rounding | Project units and display rounding match the BEP; no discipline working in different units | One model in millimetres, another in metres, with dimensions rounding differently |
| True north / project north | Both defined, with the rotation documented | Solar and shadow studies run against project north by mistake |
3. Geometry and modelling quality
| Check | Passes when | Typical failure |
|---|---|---|
| Duplicate elements | No coincident or overlapping duplicates of the same element | Copy-paste between levels leaves a stacked second copy; quantities double |
| Correct category | Elements are modelled in their proper category, not approximated with another | Ducts modelled as generic extrusions; schedules and clash rules miss them |
| In-place families | Used only where justified and listed with a reason | Dozens of in-place elements that cannot be scheduled or reliably exported |
| Element hosting | Hosted elements are attached to the correct host, not floating or hosted to a link | Doors hosted to a linked wall; the link updates and openings vanish |
| Joins and connections | Walls, floors and structural members join correctly with no gaps or unintended overlaps | Volumes and quantities wrong; gaps appear only in section |
| Geometric tolerance | Element positions fall within the BEP tolerance of the reference grid or datum | No tolerance stated at all, so “close enough” is decided per modeller |
| Stray geometry | No elements far outside the building footprint or at extreme elevation | An accidental object 400 m away extends the bounding box and slows every view |
4. Model health and performance
| Check | Passes when | Typical failure |
|---|---|---|
| Warning count | Below the project threshold and trending down, with all critical warnings resolved | Thousands of accumulated warnings nobody has read since month two |
| File size | Within the agreed ceiling for the discipline and stage | Uncontrolled growth until the model cannot be opened on standard hardware |
| Purge status | Unused families, types, materials and view templates purged before each exchange | Purge treated as optional; file bloats with content never used |
| Imported CAD | No live CAD imports inside the model; references are linked and removed when superseded | Exploded DWG geometry embedded in the model, carrying thousands of line styles |
| Links | All links resolve, use the agreed path type, and point to current Shared revisions | Links pointing at someone’s local desktop folder |
| Worksets | Named per the BEP, correctly assigned, with no elements left in a default workset | Everything on “Workset1”; no meaningful visibility control |
| Ownership | No elements left checked out or owned by a departed user | A former employee still owns half the grid lines |
5. Data, parameters and classification
| Check | Passes when | Typical failure |
|---|---|---|
| Shared parameters | All required parameters come from the single agreed shared parameter file, with matching GUIDs | Each discipline created its own “Asset_Tag” parameter; none map to each other on export |
| Classification coverage | Every element required to be classified carries a code from the single agreed system | Classification applied to mechanical only, because that team had time |
| LOIN completeness | Geometry, data and linked documentation all meet the level of information need for this stage | Geometry at LOD 400, data still at LOD 100 |
| No placeholders | Required fields contain real values — no “TBC”, “N/A”, “-“, or software defaults | A COBie export that validates cleanly and is 60% placeholder text |
| Naming of model objects | Families, types, views, sheets and schedules follow the agreed convention | Type names inherited from a manufacturer download and never renamed |
| Room and space data | Rooms bounded, named, numbered and unique; areas within tolerance of the area schedule | Unenclosed rooms reporting zero or absurd areas |
| Cross-model consistency | The same value appears the same way in the model, the schedule and the specification | Fire rating differs between the door schedule and the door family |
Our guide to LOD 100–500 covers what each level requires of geometry and data, which is the reference the LOIN check is run against.
Want this run on your models by someone who did not build them?
AMC Engineer audits federated models against your BEP, EIR and ISO 19650 — coordinates, classification, model health, clash status and data completeness — and returns a prioritised findings register with owners and deadlines, not a list of screenshots.
6. Coordination and clash status
| Check | Passes when | Typical failure |
|---|---|---|
| Federation integrity | All models required by the MIDP are present, current, and align without manual adjustment | Federated model built from last month’s structural export |
| Clash rule set | Tests, tolerances and discipline pairs match the BEP, and the rule set is unchanged since last cycle | Tolerance quietly widened to reduce the reported count |
| Severity classification | Every clash is classified Critical, Major or Minor against a written definition | A flat list of 14,000 clashes with no triage, so nobody starts |
| Critical clashes | Zero unresolved critical clashes at the exchange | Structural penetrations carried into construction as “to be resolved on site” |
| Ownership | Every open clash has a named owner and a resolution date | Clashes assigned to “MEP” as a discipline; nobody personally responsible |
| Internal clashes | Each discipline’s own model is clash-free before federation | Teams federating to find problems they should have caught alone |
| Issue round trip | Issues exported and returned in BCF with status preserved across platforms | Coordination comments living only in meeting minutes |
Our guide to BIM coordination covers the cycle these checks audit.
7. Documentation and sheets
| Check | Passes when | Typical failure |
|---|---|---|
| Sheet register | Sheets present match the register and the MIDP for this milestone — none missing, none extra | Drawings issued that appear on no register |
| Title block data | Project, revision, status, scale and issue date populated and driven by parameters, not typed | Hard-typed revision letters that no longer match the file |
| Dimension overrides | No manually overridden dimension values anywhere in the set | A dimension text edited to hide a modelling error; the model stays wrong |
| Detached annotation | Tags and dimensions reference live elements, with no orphaned or unhosted annotation | Question marks across the sheet set after a link reloads |
| View discipline | Working views are removed or clearly separated from issued views | Two hundred unnamed working views shipped with the model |
| Schedules | Schedule totals reconcile with model quantities and with the specification | A door schedule filtered months ago and never reset |
| PDF output | Issued PDFs are correctly scaled, searchable and generated from the current model | PDFs exported before the last round of changes |
8. Export, handover and asset data
| Check | Passes when | Typical failure |
|---|---|---|
| IFC round trip | Export, re-import and verify: geometry, classification, parameters, units and coordinates all survive | Export settings never tested; data loss discovered at handover |
| Export settings locked | A single documented mapping and MVD used by every task team | Each modeller using their own export preset |
| Asset register completeness | Every managed asset carries the fields the AIR requires, populated with real values | Manufacturer and serial fields blank because nobody collected them on site |
| Persistent identifiers | Asset and element IDs remain stable between data drops | GUIDs regenerated on export; the FM system cannot trace assets across drops |
| Three-way tag alignment | The tag on the equipment, the model parameter and the maintenance record all match, verified by sample | Three conventions in use; the register is unusable from day one |
| FM import test | A trial import into the operator’s CAFM or CMMS completes without manual repair | Perfect data in a structure the operator’s system cannot ingest |
| Documents linked | Every referenced O&M manual, certificate and approval is present and resolves | Document links pointing at a project server due for decommissioning |
Our guides to what LOD 500 really means and BIM in facility management cover the handover deliverable these checks protect.
Setting Pass / Fail Criteria
A number in a checklist is only useful if the project agreed it. The values below are a starting point for a BEP discussion, not a standard — a hospital MEP model and a villa architectural model have no business sharing a warning threshold.
| Metric | Working default | What drives the real number |
|---|---|---|
| Unresolved critical clashes at exchange | Zero, always | Nothing. This one is not negotiable |
| Unresolved major clashes | Zero at technical design and later | Stage; some tolerance is reasonable at developed design |
| Warning count | A stated ceiling per discipline, trending down each cycle | Model size and complexity; the trend matters more than the absolute |
| Model file size | A stated ceiling that keeps the model workable on project hardware | Hardware baseline, discipline, whether the model is split by zone |
| Classification coverage | 100% of elements the EIR requires classified | Which elements the EIR actually scopes |
| Required-field population | 100%, with zero placeholder values | Which fields the AIR designates as required at this drop |
| Positional tolerance | A stated value per discipline, in the BEP | Construction tolerance of the trade, not modelling convenience |
| Elements in a default workset | Zero | Nothing; this is a discipline issue, not a technical one |
Running the Audit: Seven Steps
- Issue a notice. Tell the team what will be audited, against which documents, on what date, and who is doing it. Unannounced audits produce defensiveness rather than fixes.
- Fix the reference set. Collect the current BEP, EIR, LOIN schedule and MIDP. If any is missing or unauditable, that is finding number one and the audit continues on that basis.
- Freeze the models. Audit a specific, recorded revision. Auditing a live model means the findings describe a state that no longer exists by the time the report is written.
- Run the automated pass first. Naming, metadata, schema, classification coverage and clash tests are machine work. Let software produce the raw findings before any human opens a model.
- Run the manual pass. Modelling judgement, documentation quality, tolerance and category correctness need a reviewer. Sample rather than exhaust — a structured sample across levels and zones surfaces systemic problems faster than a full sweep.
- Classify and assign. Every finding gets a severity, a named owner and a resolution date. A finding with no owner will not be fixed.
- Close out. Re-verify the fixes and formally close each item. Findings that roll forward unclosed across three cycles are not findings any more; they are accepted risk, and someone should say so explicitly.
What the Audit Report Contains
The report is the deliverable, and it is what an acceptance decision rests on. Four parts:
- Status dashboard. A one-glance verdict — on track, at risk or critical — with each metric shown against its previous value so the trend is visible. Critical and major clashes outstanding, model health, overdue actions, delivery compliance against the MIDP.
- Clash summary. Counts by discipline pair, classified by severity, with resolved and open figures. Every critical and major clash listed individually with an owner and a deadline.
- Model health per container. File size, warning count, coordinate status, naming status, and a health figure derived from the routine checks.
- Actions register. Every finding as a numbered item with severity, owner, due date and status, carried forward until formally closed. Overdue items escalate.
What the report should not be is forty pages of screenshots with no priority order. If the recipient cannot tell within thirty seconds what has to be fixed this week, the report has failed regardless of how thorough the audit was.
Tools That Automate the Checks
Roughly two-thirds of the checklist above is machine-checkable. Automating that portion is what makes auditing sustainable at weekly frequency rather than a milestone event everyone dreads.
| Tool type | Covers | Still needs a human for |
|---|---|---|
| Rule-based model checkers (e.g. Solibri) | Rule sets for geometry, data completeness, classification, code-style checks on IFC | Writing rules that reflect the actual BEP |
| Federation and clash tools (e.g. Navisworks) | Clash tests, federation integrity, issue tracking | Severity judgement and constructability |
| Authoring-platform checkers (e.g. Revit Model Checker, Ideate) | Warnings, worksets, naming, parameters, purge status inside the native model | Modelling-approach quality |
| CDE validation (e.g. ACC, Trimble Connect, Aconex) | Naming and metadata validation at upload, status transition rules, duplicate detection | Whether the content behind a compliant name is correct |
| Schema validators (IFC / COBie) | Structural conformance of the exchange file | Whether populated values are true |
BIM Audits on Saudi and UAE Projects
Model submission is increasingly a permitting matter
Dubai Municipality has required BIM on defined categories of project since 2013, and a circular issued in October 2023 introduced BIM model submission for new building permits in IFC format. Abu Dhabi Municipality publishes submission requirements covering naming conventions, coordinate systems and file formats referencing ISO 19650. On those projects the audit stops being an internal quality exercise and becomes a check against a submission gate — and an IFC export that has never been round-trip tested is a programme risk, not a technical detail.
Multi-nationality delivery teams make naming a real risk
A typical Gulf project team spans several countries of professional training, with consultants carrying UK, North American, Indian and European office standards into the same federated model. Naming, classification and level conventions diverge by habit, not carelessness. The audit is where that divergence surfaces — and it surfaces cheaply at developed design and expensively at handover. Our guide to BIM standards covers setting the single convention this depends on.
Bilingual content needs an explicit rule
Room names, sheet titles and asset descriptions on projects here are frequently required in both Arabic and English. Where that has not been decided in advance, the audit finds a model with mixed-language type names, inconsistent encoding, and characters that do not survive IFC export. It is a trivial requirement to state and an expensive one to retrofit — add a bilingual field rule to the BEP, then audit encoding survival as part of the export test.
Cooling plant dominates what the audit is protecting
The mechanical asset register on a building here is larger and more operationally critical than its temperate-climate equivalent. Chillers, air handling units, fan coil units, pumps and district cooling interfaces represent a large share of both capital value and operational risk, which means the data-completeness and tag-alignment sections of the checklist carry more weight than they would elsewhere. Our guide to BIM in Saudi Arabia covers the wider delivery context.
Seven Ways a BIM Audit Fails
| Failure | What it causes | The fix |
|---|---|---|
| No reference document | Findings are the auditor’s preferences; the team is entitled to ignore them | Audit against the BEP and EIR, or make their absence the first finding |
| Checks with no pass criterion | Two reviewers reach opposite verdicts on the same model | Write every check as a testable statement with a threshold |
| The producer audits their own model | Blind spots are preserved rather than found | Separate the internal check from independent acceptance; name both people in advance |
| Findings with no named owner | Nothing is fixed; the same list reappears next cycle | Every finding carries a person and a date, not a discipline |
| Clashes reported without severity | A list of thousands that nobody knows where to start on | Classify Critical / Major / Minor against a written definition before reporting |
| Same depth at every stage | Effort wasted early, risk accepted late | Set a rigour schedule per criterion per stage, agreed before the first exchange |
| No close-out | Findings roll forward indefinitely and lose all authority | Re-verify and formally close each item; escalate anything overdue |
Frequently Asked Questions
What is a BIM audit checklist?
A structured set of checks used to verify that a BIM model and its supporting information meet the requirements agreed for the project. A usable checklist states, for each item, what is being verified and what counts as a pass — a list of topic headings without pass criteria cannot be failed and therefore cannot compel a fix. The checks usually span file and CDE compliance, coordinates and setup, geometry quality, model health, data and classification, clash status, documentation, and handover data.
What is the difference between a BIM audit and clash detection?
Clash detection asks whether the disciplines physically conflict. A BIM audit asks whether the deliverable meets the stated requirement, and clash status is only one section of it. A model can be entirely clash-free and still fail an audit on coordinates, naming, classification, parameter completeness or documentation. Clash detection is a subset of an audit, not a synonym for it.
Who should perform a BIM audit?
Someone who did not produce the model. ISO 19650-4 separates the producing team’s own check before information leaves work-in-progress from the receiving party’s acceptance before publication, and both are recorded with a named individual, a date and a coded outcome. When the modeller audits their own model, the blind spots that caused the defects are preserved rather than found.
How often should BIM models be audited?
A formal audit at each milestone and information exchange, with a short recurring health check between them — warnings, file size, links and coordinate integrity — run weekly by the BIM coordinator. The depth should be proportionate to the stage: light at concept, full compliance from technical design onward, and full plus verification at handover.
What standards does a BIM audit check against?
Primarily the project’s own documents: the Exchange Information Requirements, the BIM Execution Plan, the LOIN or LOD schedule, and the MIDP. Those sit inside the ISO 19650 series, and on many Gulf projects alongside authority submission requirements such as those published by Dubai Municipality and Abu Dhabi Municipality. If none of those documents exist in auditable form, that absence is itself the first finding.
How long does a BIM audit take?
It depends on the number of models, the stage, and how much of the checklist is automated. A single discipline model with automated naming, metadata and rule-based checks configured can be reviewed quickly; a full federated milestone audit across all disciplines with a manual documentation review is a substantially longer exercise. Automating the machine-checkable portion is what makes frequent auditing sustainable rather than a dreaded milestone event.
Can a BIM audit be done on IFC models instead of native files?
Yes, and on ISO 19650 projects it often should be, because IFC is the format the exchange actually delivers. Rule-based checkers work well against IFC for geometry, data completeness and classification. What an IFC audit cannot see is the internal authoring health of the native model — worksets, warnings, family structure, purge status — so a full audit usually reviews both, and always includes an export round-trip test to confirm data survives the conversion.
What should a BIM audit report contain?
A status dashboard showing each metric against its previous value so the trend is visible; a clash summary by discipline pair and severity with resolved and open counts; model health per container covering file size, warnings, coordinates and naming; and an actions register where every finding carries a severity, a named owner, a due date and a status until formally closed. What it should not be is a long sequence of screenshots with no priority order.
Conclusion
The difference between a BIM audit that changes a project and one that produces a filed document is not thoroughness. It is whether each check can be failed.
That requires three things settled before the first exchange: a reference document specific enough that two reviewers reach the same verdict, thresholds agreed in advance rather than negotiated after a model fails, and a named person on both sides of every acceptance gate. Add automation for the conformance checks, keep a human on the correctness ones, classify every finding by severity with an owner and a date, and close items out formally.
Do that and the audit stops being an inspection the team endures and becomes the mechanism that keeps the model worth relying on — through coordination, through construction, and into the decades the building is operated.
Let’s audit the model while the findings are still cheap to fix.
AMC Engineer delivers independent BIM audits, federated LOD 300–500 modelling, clash detection and construction documentation for contractors, consultants and asset owners across Saudi Arabia and the UAE.
