BIM Deliverables Explained: Models, Drawings, Data, and What Clients Should Require
Clear guide to BIM deliverables: native models, IFC, drawings, schedules, COBie, and QA docs. Learn what owners should require by phase for EU/USA projects.
BIM Deliverables Explained: Models, Drawings, Data, and What Clients Should Require
“BIM deliverables” is one of the most abused phrases in project documents. Some clients mean a pretty Navisworks file. Others mean a full ISO 19650 information set with validated IFC, native models, drawings, and asset data. If the deliverable list is vague, teams argue at handover while the useful window for fixing information has already closed.
This guide explains BIM deliverables in practical terms: what they are, how they differ by phase, what good acceptance criteria look like, and how Scan to BIM packages fit. It is written for owners, project managers, and BIM leads who need contractual clarity.
Name formats, LOD, CRS, and acceptance tests in the deliverable list.
A BIM deliverable is any information product generated from or for the BIM process that a party must submit against requirements. That can include:
Native authoring models (RVT, PLN, DGN, etc.)
Exchange models (IFC and other open formats)
Federated coordination models
Drawings and sheets extracted from models
Schedules, quantities, and data tables
Asset information (COBie or owner-specific schemas)
Point clouds and Scan to BIM existing-conditions models
Reports: clash, QA, registration, BEP compliance
Viewer packages and documentation of coordinate systems
Problems arise when contracts say “provide BIM” without specifying format, purpose, Level of Information Need, acceptance tests, or update cadence. Teams then deliver what is convenient, not what is usable.
At handover, owners discover missing attributes, broken classification, drawings that do not match models, or Scan to BIM models without residual reports. The deliverable existed as a file. It failed as information.
Why It Happens
1. Copy-paste EIRs. Requirements borrowed from unrelated projects ask for everything and prioritize nothing.
2. Confusing LOD theater with purpose. “LOD 400 for all elements” is not a deliverable strategy; it is a budget explosion.
3. Drawing primacy unresolved. If PDFs remain the only contractual truth, model deliverables become optional extras.
4. No acceptance criteria. Without measurable checks, “complete” is subjective.
5. Software-centric specs. Mandating a brand without defining information content produces pretty, empty models.
6. Late FM involvement. Asset fields are invented at week 90 instead of week 0.
7. Scan to BIM treated as geometry only. Clients accept visually dense models with no stated tolerances or inclusion/exclusion lists.
8. Version chaos. Deliverables uploaded without revision discipline cannot support decisions.
Industry Examples (EU/USA)
European Union
EU public work often references ISO 19650 information management. Deliverables are framed as information containers satisfying Exchange Information Requirements (EIR) and Asset Information Requirements (AIR).
Typical EU expectations may include:
Native models plus IFC exports at defined milestones
Documentation of Level of Information Need
CDE workflow compliance
Coordination reports
As-built information aligned to owner asset systems
For existing assets: point cloud archives and modeled deliverables with QA
Failure mode: compliance paperwork without content validation. Success mode: tested IFC property mapping, clear purpose per milestone, and rejection rights for nonconforming information.
United States
US deliverables vary by owner. Some federal and institutional clients specify formats and COBie. Private developers may require coordination models and record drawings, with uneven asset data needs. Design-build projects often define progressive model deliverables tied to design packages.
US Scan to BIM scopes commonly list:
Registered point clouds
Modeled disciplines at stated LOD
Sheets/plans/sections
Optional clash or deviation reports
The strongest US specs state tolerances, inclusion lists, coordinate systems, and software versions—then require a sample area approval before full production.
Technical Explanation
Deliverables should map to EIR clauses and CDE states.
Deliverable categories
A. Geometric models
Authoritative 3D representations for design, coordination, fabrication support, or as-built record.
B. Exchange models
IFC or other neutral formats for interoperability, long-term access, or downstream FM/CAFM import.
C. Derived documents
Plans, sections, elevations, details, schedules produced from models.
D. Structured data
Parameters, classification (OmniClass/Uniclass/etc.), COBie sheets, asset registers.
E. Reality capture packages
Raw/registered clouds, derivatives, registration reports, control summaries.
F. Process evidence
BEP, clash reports, QA checklists, model health audits, issue logs.
Purpose controls content
The same “architectural model” differs if used for:
Massing planning
Coordination
Building permit
Fabrication of façades
FM space management
Specify purpose first; LOD/LOI follows.
Acceptance tests (examples)
File opens in agreed software/version
Shared coordinates verified against control
Naming and classification compliance rate
Required properties populated for listed asset types
IFC property validation against mapping table
Drawings match model revision ID
Scan to BIM residuals within tolerance at checkpoints
No banned placeholder content in released zones
Scan to BIM deliverable package (typical)
Registered cloud (archive format) + report
Modeling derivative clouds
Native existing-conditions model(s)
Optional IFC
Sheet set
Modeling inclusion/exclusion matrix
QA residual summary
CRS and origin statement
Phase-based deliverable thinking
Concept, schematic, detailed design, construction, and handover do not need the same package. Early phases may need federated coordination models and key schedules. Mid phases add fabrication support extracts and tightened LOI. Handover adds asset data, as-built geometry, and operation manuals links. Copying the handover list into schematic design creates waste and false noncompliance. Build a phase matrix: rows are deliverable types, columns are gates, cells state required, optional, or not applicable.
Native vs exchange vs viewer packages
Native files support future editing by the same platform community. Exchange files (IFC and similar) support open checking and longevity. Viewer packages support broad communication. Specify which is authoritative for which decision. A common mature pattern: native authoritative for design edits, IFC authoritative for open validation rules, PDF still authoritative for permit sets if legally required—explicitly stated so nobody assumes otherwise.
QA and evidence as deliverables
A model without evidence is an opinion. Require clash summaries at coordination gates, model health audits for authoring files, IFC validation reports when IFC is required, and Scan to BIM residual reports for existing-conditions packages. These documents should be listed in the deliverable register with naming and retention rules. They are not optional extras for conscientious teams only.
Commercial linkage
If deliverables matter, connect them to payment or release gates. Sample area acceptance before mass Scan to BIM production is one of the highest-leverage controls available to clients. Mid-project IFC mapping tests prevent handover meltdowns. Drawing-model consistency checks prevent parallel truths. Write rejection rights clearly: nonconforming uploads do not count as submitted.
Multi-building and program standardization
Campus and portfolio programs should standardize the deliverable register once. Vendors then price consistently and QA becomes comparable across buildings. Include a shared coordinate policy, space naming standard, and asset field dictionary at program level. Per-building exceptions are documented deltas, not reinventions.
Best Practices
Pretty views are not acceptance — deviation and checklist evidence are.
Define deliverables by decision gate, not by software.
Separate mandatory vs optional items clearly.
State Level of Information Need per asset class and phase.
Require sample approval before mass production.
Link drawings and data to model revision IDs.
Include QA reports as first-class deliverables.
Map IFC properties early and test twice.
For Scan to BIM, publish tolerances and exclusions.
Align handover data to the real FM system fields.
Pay for information quality—cheap incomplete BIM costs more later.
Existing architectural model — RVT 20xx — mid and final — LOI per matrix — acceptance: sample + residuals
Coordination IFC — IFC2x3/IFC4 as specified — each design gate — mapping table vN — acceptance: checker ruleset
Federated coordination file — NWD/other — weekly peak — acceptance: link currency list attached
Asset data table — COBie or owner CSV — handover — fields from FM template — acceptance: required fields ≥ threshold
Sheet set — PDF + native sheets — per package — revision matches model ID — acceptance: spot check list
Responsibilities and appointment clarity
ISO-aligned projects appoint parties for information tasks. Even outside ISO language, write who produces, who reviews, who accepts, and who maintains after handover. Orphan deliverables—everyone assumed someone else would fill COBie—are classic failures. Put names and roles in the register.
Avoiding deliverable inflation
More files are not better. Each deliverable should map to a decision or obligation. If nobody will open it, do not require it. Inflation creates checkbox compliance and hides the few artifacts that matter. Ruthlessly edit the register with the owner and lead designer present.
Scan to BIM completeness statements
Require a completeness statement: percentage of scoped areas modeled, list of exclusions, list of low-confidence zones, and recommendations for additional capture. This single page prevents the false assumption that “BIM received” means “building fully known.”
Case Study
Client need: University renovation program requiring existing-conditions BIM for multiple campus buildings before design awards.
Initial RFP language: “Provide LOD 300 BIM of existing buildings.”
Problems that language caused historically: Inconsistent element inclusion, no tolerances, missing data fields, unverifiable accuracy.
Revised deliverable register included:
Registered E57 clouds per building with control residuals
Revit existing-conditions models by discipline split
Inclusion matrix (structure, architecture, main MEP > stated sizes)
Stated modeling tolerances at QA checkpoints
Room/space schedule matching campus standards
IFC2x3 coordination view for archive
QA report template
Outcome: Bidders priced more consistently. First building sample was approved with minor comments. Later buildings arrived with fewer completeness disputes. Design teams trusted the models enough to use them for early coordination rather than redrawing.
Clarity in deliverables improved both cost certainty and technical usability.
Common Mistakes
“LOD 400 everywhere.”
Asking for IFC without property mapping.
Accepting models without QA reports.
No coordinate system statement.
Delivering sheets disconnected from model revisions.
Forgetting space/room data for FM.
Treating Navisworks NWD as the only model deliverable.
No exclusion list for Scan to BIM (everything is “in” until it isn’t).
Demanding native files the owner cannot maintain.
Handover dumps in the last week with no review period.
Expert Tips
Write acceptance tests that a junior reviewer can execute.
Keep a deliverable index PDF listing every file, revision, and hash for major gates.
If owners cannot use Revit, still consider native files for future consultants—plus IFC for longevity.
For asset data, start from the FM system’s import template, not from a generic COBie fantasy.
Require model health metrics (warnings, in-place families explosion, unused links) as part of acceptance for authoring files.
On multi-building programs, standardize the deliverable register once and reuse.
Distinguish coordination IFC from asset IFC—different mapping burdens.
Make “incomplete known issues list” mandatory; honest gaps beat silent omissions.
Future Trends
Deliverables are shifting from file drops to validated information APIs and CDE states. Owners will increasingly require machine-checkable rules for IFC and parameter completion. Digital twins will demand ongoing update deliverables, not one-time as-builts.
Scan to BIM scopes will more often specify dual outputs: geometry for design and structured existing-asset data for FM. Automated checkers will reject uploads that fail schema rules before humans review.
The winners will specify less theater and more testable purpose.
Language to borrow for your next RFP
Prefer: “Provide existing-conditions architectural and structural Revit models for Building A per Inclusion Matrix Rev.3, modeling tolerances per QA Sheet Rev.2, shared coordinates per CRS Memo Rev.1, including residual report at checkpoints listed in Appendix B. Deliver RVT (version X) and IFC (schema/MVD Y) with matching revision IDs. Sample Zone S1 must be accepted before production of remaining zones.” Avoid: “Full BIM LOD 400 of the entire site ASAP.”
Handover event design
Schedule a handover review meeting with live model navigation, not only file transfer receipts. Walk through known issues, demonstrate coordinate proof, open a sample IFC in the checker, and confirm FM import of a sample asset table. Record attendance and open actions. Files dumped on a Friday evening without review are not a handover; they are an abdication.
Keeping deliverables alive after practical completion
If the owner will renovate again in five years, define who maintains the as-built model and how updates from future scans enter the archive. Orphaned handover models decay. Appoint maintenance responsibility or consciously accept that the next project will rebuild existing conditions again—and budget for that choice honestly.
FAQ
Are drawings still BIM deliverables?
Yes, when extracted from and consistent with the model. Many contracts still require them.
Is IFC mandatory?
Only if requirements say so—but it is often wise for longevity and multi-software teams.
What should a minimum Scan to BIM deliverable include?
Registered cloud + report, model, CRS statement, inclusion/exclusion matrix, and QA residuals.
How detailed should COBie be?
Only as detailed as the owner can maintain. Empty mandatory fields are worse than a smaller real set.
Who accepts deliverables?
A named information approver with criteria—not an informal “looks fine.”
Can one NWD replace native models?
For viewing/coordination, sometimes. For future editing and responsibility, usually no.
Worked Example: Mid-Size Renovation Package
Imagine a 12,000 m² office renovation. A coherent deliverable set might include: registered E57 archive with control report; floor-tiled RCS modeling clouds; architectural/structural existing RVT at agreed matrix (walls, slabs, columns, cores, main ceilings hierarchy—not every chair); main MEP above stated sizes; room/space schedule aligned to owner naming; coordination IFC at two gates; clash report for existing vs new at DD; QA residual sheet; and a known-issues list for unscanned ceiling voids. Drawings: plans/sections as required by the designer’s workflow. Not included: furniture, decorative objects, every conduit below threshold, and speculative hidden services without evidence.
That package can be priced, scheduled, and accepted. A vague “BIM of the building” cannot. Use this level of specificity in your next appointment documents.
Roles Across the Deliverable Lifecycle
Producers create files to specification. Reviewers check acceptance tests. Approvers formally accept for a gate. Maintainers keep information alive after handover if required. Confusing these roles produces either rubber-stamp acceptance or endless unowned debate. Name them in the BEP and appointment documents. For Scan to BIM, the producer may be an external specialist while the design BIM manager remains approver—state that clearly so comments carry authority.
Also define how partial acceptance works. Accepting Zone A should not silently imply Building B is accepted. Use registers with status columns. Payment schedules can follow accepted rows. This is how programs scale without drowning in email interpretations of “the BIM is basically done.” For public EU work, align the register language with information container expectations so compliance evidence and technical usefulness travel together rather than fighting each other. In USA institutional work, map the same register to owner BIM guidelines and COBie or proprietary FM templates so “handover” means importable data, not a folder of hopeful files. Either way, the register is the contract’s friend: it turns BIM from a vibe into a checklist with teeth.
Deliverable Ambiguity Killer Questions
Ask at kickoff: What decisions will this model support? Who accepts residuals? Which categories are excluded on purpose? Which drawings are contractual vs informative? What happens when cloud and drawings conflict? Write answers into the deliverable schedule—ambiguity is the root of most BIM disputes.
Summary
BIM deliverables are purposeful information products—models, exchanges, drawings, data, reality capture, and QA evidence—defined by use case and validated by acceptance tests. EU ISO-aligned projects and USA owner standards differ in vocabulary, not in the need for clarity. Vague LOD slogans create disputes; deliverable registers create usable outcomes.
CTA
Defining a Scan to BIM or existing-conditions deliverable set for your next project? Bimzstudio helps clients and project teams specify practical packages—geometry, data, and QA—matched to real design and FM uses. Share your project type and handover goals to refine a deliverable register that bidders and modelers can actually execute.
