Point Cloud QA for Scan to BIM: The Complete 2026 Guide

# Point Cloud QA for Scan to BIM: The Complete 2026 Guide

TL;DR

• Point cloud QA is a measurable acceptance test against a stated tolerance — checked at four stages (field, registration, deliverable, model) — not a one-time visual review of the finished cloud.
• USIBD Level of Accuracy (LOA 10–50) governs dimensional fidelity; BIMForum Level of Development (LOD 100–500) governs model element development. They answer different questions and neither substitutes for the other.
• A registered point cloud is only as trustworthy as its documented residuals: cloud-to-cloud RMS, maximum single-station residual, and control-network closure all belong in a written registration report.
• Independent check measurements — physical shots taken with a total station or calibrated scale bar, separate from the scan data — are the only way to confirm a registered cloud matches the real building.
• A full, itemized QA checklist with pass/fail criteria and a sign-off column, published below, is the reproducible procedure the market has described but rarely shown in full.

Jump to: What QA is · Set the target · Field QA · Registration QA · Deliverable QA · Model QA · Full checklist · When QA fails · FAQ

What point cloud QA is, and what it is not

Point cloud QA is a measurable acceptance test: a stated tolerance, a defined check method, and a pass/fail result recorded against each one. It is not a visual scroll through the cloud looking for obvious gaps, and it is not the same procedure as model QA, which checks a different artifact against a different reference.

The standards stack behind a real QA procedure has five parts. USIBD Level of Accuracy (LOA) Specification C120 / Guide C220 defines dimensional fidelity bands and separates Measured Accuracy (how the field data was captured) from Represented Accuracy (how faithfully the deliverable reflects it). BIMForum's Level of Development (LOD) Specification (cite by the edition year in use on the project) governs how developed a model element is — its geometry and attached data — and is not a proxy for accuracy. ASTM E3125-17 is the test method for evaluating a 3D imaging system's point-to-point distance performance, i.e., how a scanner's stated spec gets verified in the first place. ISO 17123-9 covers field procedures for testing terrestrial laser scanners. JCGM 100 (the GUM) is the reference for combining multiple error sources — instrument noise, angular error, registration residual, target centering, modeling abstraction — into one stated uncertainty. This guide cites each standard by name and scope only; it does not quote or invent clause text or table values from any of them.

The distinction worth repeating because so few pages state it plainly: LOD describes what a model element is and how developed its geometry and data are. LOA describes how closely a spatial dataset matches physical reality. A wall modeled at LOD 300 says nothing on its own about whether that wall face sits 5 mm or 50 mm from where the real wall stands — that is an LOA and registration question, answered separately.

How do you set the accuracy target before you scan?

The accuracy target is chosen before the scanner is turned on, not inferred afterward. It has five components: the USIBD LOA band tied to the use case, the LOD tier by discipline, the point density at a stated range, the coordinate system and project control, and a defined occlusion allowance.

Choosing LOA by use case. LOA is a project decision driven by what the deliverable will be used for — renovation coordination needs a tighter band than a conceptual massing study. This table shows how the band, typical tolerance, and cost implication move together (bands per USIBD C120/C220; consult the current edition for the full band definitions before writing a contract).

LOD should be set separately, by discipline — architectural shell, structure, and MEP frequently carry different LOD tiers on the same project (see LOD 200 vs 300 vs 400 for what changes between tiers). Point density needs a number, not an adjective: state it as points per square meter and as millimeter spacing at a stated range, since spacing widens with distance from the scanner. The coordinate system, units, and project control (state plane, project-specific, or tied to a survey benchmark) must be fixed before the first scan is registered against it. Occlusion allowance — what percentage of a surface can go unscanned before a QA check fails — should be written into the scope, not decided ad hoc in the field.

This target-setting section is the front half of a scope of work; the full copy-pasteable scope of work template carries these same fields forward into a contract-ready document.

What field QA checks should run before the crew demobilizes?

Field QA is the numbered sequence a crew runs before leaving the site, because every defect caught in the field costs a signature; every defect caught after demobilization costs a return trip. Each step below carries a pass criterion, checked on-site against the project's stated LOA band.

1. Coverage verification — walk the captured area against the floor plan; pass if no unscanned zone exceeds the occlusion allowance set in scope.
2. Scan-position spacing — confirm station or path spacing matches the interval set for the target LOA band; pass if no gap in coverage exceeds that interval.
3. Overlap percentage between adjacent scans/passes — pass if overlap meets or exceeds the project-specified minimum (higher LOA bands require greater overlap for reliable cloud-to-cloud registration).
4. Target placement and geometry — targets set in a stable, non-collinear pattern visible from at least two scan positions; pass if geometry supports triangulation without a weak axis.
5. Control observation — survey control points tied into the network with a total station or GNSS as scoped; pass if every control point required by the scope is observed and logged.
6. On-site preliminary registration — a rough registration run in the field, before demobilizing; pass if it shows no gross misalignment or missing station.
7. Photo/panorama capture — reference imagery captured at each station or interval; pass if coverage matches the scan positions logged.
8. Site log — date, crew, equipment serial numbers, weather/lighting conditions, and any access restrictions recorded; pass if the log is complete enough to reconstruct the day without the crew present.

What registration numbers actually need to pass?

Registration QA is where a cloud earns the accuracy figure printed on the deliverable, and it is the single biggest gap in the published competitive material — every source names registration as critical and stops short of a number. The two registration methods are target-based (survey-controlled, using placed targets with known coordinates) and cloud-to-cloud, or ICP, registration (aligning overlapping geometry directly). Most Scan to BIM projects use both: cloud-to-cloud for station-to-station alignment, tied back to survey control for absolute position.

A registration report should state, at minimum: the bundle adjustment result, cloud-to-cloud RMS per station pair, the maximum single-station residual, loop closure across any closed traverse, control-network closure, and a record of any statistical outlier removal applied before the final adjustment. These thresholds are project-specified against the chosen LOA band — a tighter band requires a tighter maximum residual — but every number reported should be a residual actually measured, not a spec-sheet figure.

A worked error budget. Combining independent error sources follows JCGM 100 (GUM) principles: sum contributing variances and take the root of the sum of squares (RSS) for a combined estimate, while the worst case is the simple arithmetic sum. A representative stack for a survey-controlled terrestrial or mobile scan might include: instrument range noise, angular encoder error at the working range, registration residual from the adjustment, target-centering error, and modeling abstraction error (the simplification inherent in fitting a plane or a family to point data). RSS combination of independent sources will always produce a smaller combined figure than simple addition, because it accounts for the fact that unrelated errors rarely all peak in the same direction at once — which is why a documented registration with real residuals supports a tighter stated accuracy than a worst-case sum would suggest.

How do you verify the point cloud against the real building?

Deliverable QA answers a question registration numbers alone cannot: does the registered cloud actually match the physical building, not just itself? That requires independent check measurements — physical distances taken separately from the scan data and compared against the same distances measured in the cloud.

Independent checks are typically taken with a total station, a calibrated scale bar, or a disto (laser distance meter) verification against known points, and they must be independent of the registration process — measuring points that were not used as control. A representative sample size is defined in scope before capture, and the QA pass criterion is a stated percentile of checks falling inside the project's tolerance (for example, requiring a high percentage of check measurements to land within the registered accuracy figure, with none exceeding a defined outer limit).

Zealot's own worked example, documented on a 38,400 sq ft occupied hospital wing project: 36 independent QC checks, 4.2 mm mean error, against a ±6 mm registered accuracy tied to plant/building control. Every check measurement, its location, and its deviation from the registered cloud was logged and reported alongside the deliverable — that documentation, not the accuracy figure alone, is what makes the number verifiable. Documentation practice should follow the same discipline described in how to vet point cloud accuracy before hiring a provider: ask for the check-measurement log, not just the summary statistic.

How do you verify the BIM model against the cloud?

Model QA is the last stage and the one most often skipped: it verifies the finished model geometry against the registered cloud that generated it, not against the original design intent. Cloud-to-model deviation analysis measures, at sampled points or across full surfaces, how far a modeled face sits from the point cloud data it was built from.

Deviation tolerance thresholds should be set by discipline before modeling begins — architectural shell, structure, and MEP routing carry different acceptable deviations depending on the LOD and LOA agreed for each. Deviation heat maps (color-coded visualizations showing where a model element deviates most from the cloud) are the standard way to communicate this at a glance; tooling categories used for this analysis include Navisworks, CloudCompare, and dedicated deviation-analysis software, named here as categories without endorsing a specific vendor. Zealot's stated commitment on Scan to BIM deliverables: model faces hold ±10 mm to the registered cloud at LOD 300. That figure describes the model-to-cloud tolerance specifically — it is not a substitute for the cloud-to-building tolerance verified in deliverable QA above, and both numbers should appear in a complete QA report.

For teams reviewing a model before formal handoff, Revit checks before hiring a Scan to BIM provider covers what to look for from the receiving end, and how poor point clouds disrupt BIM coordination traces what happens downstream when this stage is skipped.

What is the full point cloud QA checklist?

This is the complete procedure, published inline, with a pass/fail criterion and a sign-off role for every item. No item here is gated behind a separate download.

What happens when a QA check fails?

A failed QA check triggers one of three responses, decided by what failed and why: a re-scan of the affected area, an adjustment within existing data (if the failure is a registration or modeling issue rather than a coverage gap), or a documented deviation accepted by the client with a written exception. The trigger and the response should be defined in the contract before work starts, not negotiated after a failure.

Who pays depends on cause. A failure traced to access restrictions, occupant activity, or site conditions the client controls is typically treated differently from a failure traced to the provider's process — this allocation should be written into the subcontract or service agreement in advance, not assumed. Discovered conditions — physical building conditions revealed by the scan that were not previously documented — are handled as a change-order condition separate from a QA failure, since they represent new information rather than a data quality defect. A holdback tied to QC pass, releasing final payment only after the QA report is delivered and accepted, is a reasonable and increasingly common contract term that protects both sides: the client confirms quality before releasing funds, and the provider has a clear, objective release trigger rather than a subjective one.

Frequently Asked Questions

What registration error is acceptable for Scan to BIM?

Acceptable registration error is set by the project's LOA band, not a universal number. Zealot's house standard is ±5 mm survey-grade registered accuracy, tied to surveyed control with residuals reported and independent check measurements confirming the cloud against the real building — the condition attached to the number matters as much as the number itself.

How do I verify a point cloud is accurate?

Request the registration report (bundle adjustment, cloud-to-cloud RMS, control-network closure) and the independent check-measurement log — physical distances measured separately from the scan and compared against the same distances in the cloud. A stated accuracy figure without either document is unverifiable.

What is USIBD LOA 20 vs LOA 40?

Both are bands in USIBD's Level of Accuracy specification (C120/C220), with LOA 20 representing a looser dimensional fidelity band suited to conceptual or planning work and LOA 40 a tighter band suited to MEP coordination or retrofit work. Consult the current USIBD C120/C220 edition for the specific numeric definitions of each band before writing them into a contract.

Does LOD 300 mean 300 mm accuracy?

No. This is a widespread and costly misconception. LOD describes how developed a model element's geometry and data are, per the BIMForum LOD Specification — it carries no numeric accuracy value at all. Dimensional accuracy is governed separately by USIBD LOA and by the registration and model-to-cloud tolerances documented in the QA report.

How many check measurements should I take?

Sample size is defined in the project scope, not fixed universally, and should scale with building complexity and the LOA band in use. Zealot's documented hospital-wing project used 36 independent QC checks across 38,400 sq ft; the appropriate count for a given project is set before capture and stated in the QA plan.

Who is responsible if the model doesn't match the building?

Responsibility depends on which QA stage failed. A registration or modeling defect traced to the provider's process is typically the provider's responsibility to correct; a discrepancy caused by a physical condition not previously documented (a discovered condition) is generally handled as a change-order item, not a QA failure. Writing this allocation into the contract before work starts avoids the dispute later.

Can QA be done after delivery?

Some checks — model QA against a delivered cloud, for instance — can be run by the receiving team after delivery. Field and registration QA cannot be reconstructed after the fact if they were skipped during capture, which is why field-stage checks (coverage, overlap, control observation) must be completed before the crew demobilizes.

What should a registration report contain?

At minimum: the bundle adjustment result, cloud-to-cloud RMS per station pair, the maximum single-station residual, loop closure, control-network closure, and documentation of any statistical outlier removal. A report that states only a final accuracy figure without these supporting values does not meet a reproducible QA standard.