The QA report is the document that turns a captured cloud into an audit-defensible deliverable. It's also the part most buyers don't know to ask for, the part most providers don't ship unprompted, and the part that determines whether your accuracy claim survives a third-party review.
The accuracy claim on a LiDAR delivery — "±20 mm vertical RMSE", "engineering-grade", whatever the marketing line is — is worth exactly as much as the evidence that backs it up. The evidence lives in the QA report.
If you've ever opened a delivery and found a folder of LAS files plus a one-page PDF that says "QA passed", you know what an inadequate QA pack looks like. If you've never opened a proper one, this article walks through what should be there, why each section matters, and what to do when a section is missing.
Three things, in roughly this order of importance:
Evidence for the accuracy claim. Anyone reading the delivery can see exactly how the accuracy number was measured, what the residuals look like, and whether the workflow was defensible.
A diagnostic if something goes wrong downstream. When the design team finds anomalies in the DTM six weeks later, the QA report is the first place to look — usually the issue is already documented.
A re-processing reference. Capture parameters, control tie, sensor configuration and processing pipeline are all captured so the data can be re-processed against new requirements without re-flying.
A delivery without a QA report can't do any of these. A delivery with a 200-word summary PDF can do them poorly.
Project name, client, site location, project ID, delivery date, delivery scope, deliverable manifest, contact for queries. Boring but essential — every section that follows is meaningless without unambiguous identification of which capture it refers to.
What sensor, what altitude, what swath geometry, what flight date window, what conditions:
These parameters determine what the data is capable of, and they shouldn't be inferred from the LAS files alone.
The post-processed kinematic solution that georeferences every return:
A flat tight covariance through the flight = good. Spikes or wide covariance bands during a flight segment = a localised problem the downstream cloud inherits.
LiDAR captures are typically multi-strip; the strips have to agree at their overlaps. The strip-alignment report shows:
For an engineering capture, overlap RMSE under 30 mm is the rough threshold; under 15 mm is good; over 50 mm needs investigation.
The most important section. Independent ground control points captured by the LiDAR but NOT used in the trajectory solution. For each checkpoint:
Aggregate statistics:
A reputable QA report shows at least 20 independent checkpoints across the project area. Fewer than 10 starts to lose statistical weight. Checkpoints clustered in one area aren't representative of the rest.
How well the algorithm + manual review classified the cloud (see ground classification for the algorithm details):
The class population alone surfaces obvious problems — a forested site reporting 60% ground / 30% vegetation is almost certainly mis-classified. A reputable report shows you which way the classification skewed.
A raster showing the actual achieved point density per cell across the project area:
Density variance affects DTM accuracy locally — areas with sparse density support coarser interpolation. The coverage map shows where the cloud is dense, where it isn't, and whether downstream deliverables in sparse areas should carry tolerance flags.
Specific to the DTM and DSM deliverables (separately from the cloud itself):
Surface generation is its own processing stage that can introduce artefacts the cloud doesn't have. The surface QA records the processing choices so they can be challenged if downstream analysis surfaces anomalies.
Every file shipped, with format, size, scope and intended downstream consumer:
A delivery without a manifest is a folder full of files. A delivery with a manifest is auditable.
Named individual, role, signature, date. The person who has reviewed the entire QA pack and is asserting it. This person should ideally not be the same person who ran the processing — independent QA is the convention.
The sign-off block is often the section that providers skip when under time pressure. It's also the section regulators and auditors look for first.
If you read only one section of a QA report, read the residuals. Five things to check:
RMSE. The aggregate accuracy claim, in mm. Should match the project's stated tolerance.
Distribution. RMSE alone hides the tails. A capture with 20 mm RMSE and a maximum residual of 40 mm is healthy. A capture with 20 mm RMSE and a maximum residual of 180 mm has a localised problem the headline number doesn't surface — go find it.
Mean. Should be near zero. A non-zero mean indicates systematic bias — the cloud is consistently above or below truth. Possible causes: control tie issue, datum error, sensor calibration drift. None of them should ship undocumented.
Per-cover-class breakdown. Bare-ground checkpoints should be tightest; canopy checkpoints looser. If they're not stratified, the report is hiding variance in the headline number.
Spatial distribution map. Where ARE the checkpoints? A clustered set in one area doesn't validate the rest of the project. Should cover the project area roughly uniformly.
Patterns we see in marginal QA packs:
"Internal consistency: N mm" quoted as accuracy. Internal consistency measures whether overlapping strips agree with each other. It says nothing about whether the absolute georeferencing is correct. A capture can be internally consistent to 5 mm and absolutely wrong by 100 mm due to a control tie error.
Sensor specification quoted instead of measured residuals. "Sensor accuracy: ±10 mm" is the manufacturer's number for what the sensor can do under perfect conditions. It is not what your project achieved. Always look for measured residuals at independent checkpoints.
No PPK reference, RTK described as the workflow. RTK alone is fine for some applications but isn't audit-defensible for engineering work (details here). A QA report that doesn't mention PPK is signalling something about the workflow.
Single aggregated residual number with no breakdown. "RMSE: 22 mm" with no histogram, no per-cover stratification, no maximum residual, no spatial distribution = a number that survives a quick read and falls apart under any review.
Sign-off by the processor. Independent QA is the convention because the person who ran the processing has a bias to find the processing acceptable. A reputable shop has someone else QA the work.
For any section absent from the report, two questions:
Was this section measured at all? Sometimes the measurement exists but wasn't included in the package — happy to add a page. Other times the measurement wasn't done, which is more serious.
What's the underlying file? Trajectory covariance, base station RINEX, control checkpoint CSV, classification confusion CSV — all are file-backed. A vendor that can't produce the file isn't withholding it from you; it doesn't exist.
If a section's underlying file genuinely doesn't exist, the delivery isn't audit-defensible. That may be acceptable for planning-grade work; it isn't for engineering deliverables.
Not every project needs the full ten-section pack. Honest expectations by tier:
The cost of the QA pack scales with the tier — typically 5–10% of total project cost at engineering tier, less for lighter work. Worth scoping at quote time so it's not a delivery surprise.
The QA report is the document that turns a captured cloud into an audit-defensible deliverable. Ten standard sections cover metadata, capture, trajectory, alignment, residuals, classification, density, surface QA, manifest and sign-off. The residuals section is the headline; everything else either contextualises or stress-tests it.
If a delivery arrives without a substantive QA pack, that's worth flagging at acceptance — not so much because the data is necessarily bad, but because no-one can validate it without the backing documentation. And without validation, the accuracy claim isn't worth more than the marketing it was written for.
Every engineering-tier capture we run lands with the ten-section QA report, signed off independently, with the underlying files archived. Tell us your acceptance criteria — we'll meet them in writing.