Design construction payment audit sampling by reconciling the complete population, defining the question, selecting risk-based items and including ordinary transactions that test false positives. Report the selected count and value, selection method and exclusions. A targeted sample does not establish a portfolio-wide error rate.
What to take away
- Reconcile the population before sampling.
- Separate targeted review from statistical estimation.
- Include clean records to test review precision and effort.
Decide what the sample must establish
An exploratory diagnostic asks whether useful, reproducible exceptions exist. A payment control tests whether specified reviews operated. An estimate of population misstatement requires a defensible statistical design. State the objective before choosing records, since the same sample will not automatically answer all three.
Define the sampling unit: a payment, application, change, line item or contract. Record the population date, size, total value and currency. If a large application contains many lines, clarify whether selecting it means reviewing every line. The coverage statement must describe the actual work performed.
Combine risk selections with comparison records
Risk indicators might include unusually large changes, repeated invoice references, manual approval overrides, missing credits or transfers between projects. Preserve the rule that selected each record. Do not select only cases someone already believes are wrong and then present the resulting exception rate as typical.
Add ordinary records and known clean cases to test the method. Include different document qualities and relevant contract variations. A review system that finds a planted error but challenges every clean invoice can create more work than it saves. Measure the evidence needed to clear a valid item as well as the time needed to confirm an exception.
| Illustrative stratum | Purpose | Reporting limit |
|---|---|---|
| Large-value selections | Review concentrated exposure | Not a representative error rate |
| Override selections | Test authority path | May overrepresent risk |
| Routine comparison records | Test false positives | Not necessarily random |
| Randomly selected records | Broaden observation | Inference depends on design |
| Known clean cases | Validate expected treatment | Not independent prevalence evidence |
Worked example: 12 exceptions do not prove a 40% portfolio rate
A fictional population contains 500 payments totaling $25 million. The reviewer selects 20 risk-flagged items and 10 routine comparison items. Twelve of the 30 selected records need further evidence. That is 40% of the selected set, but it is not evidence that 40% of all 500 payments are wrong.
After review, suppose four items are confirmed calculation errors, six are cleared and two remain unresolved. Report all three outcomes. Show both count and value coverage, and distinguish proposed adjustments from settled results. Never project the selected exception dollars across the $25 million without an appropriate estimation method and qualified review.
Make selection and re-performance possible
Save the source export, selection rules, selected identifiers and any replacements. Record why an inaccessible item was replaced and keep the limitation visible. Replacing difficult records with convenient ones can bias the result and conceal the integration burden.
For each item, retain the source basis, calculation, response and independent reviewer decision. A second reviewer should be able to follow the finding without asking the original analyst to reconstruct it. Document any change in methodology during the pilot so before-and-after performance is not falsely compared on different tests.
Use the sample to decide the next scope
Compare validated value with review effort, false positives and unresolved data access. Decide whether the next phase should expand the same contract family, improve evidence collection or stop. The absence of a confirmed recovery in a targeted diagnostic is a result, not a reason to relabel unsupported flags as savings.
For a Buildalytic discussion, bring clean and problematic records together and agree the human acceptance criteria in advance. Additional analytics or connectors should be scoped separately from currently published follow-up workflows. A recurring assurance proposal becomes credible when the same tests work across repeat portfolios with manageable reviewer effort.
Common questions
Can I extrapolate a targeted sample's error rate?
Not as a representative population estimate. Risk-based selection intentionally changes the mix. Statistical inference requires an appropriate design and interpretation.
Why include clean payments?
They test false positives, reviewer burden and whether the method can recognize correct treatment, not just find suspicious cases.
Sources and editorial notes
Prepared with AI assistance. Reference date: 2026-11-05. Worked examples are illustrative and are not customer results. Product details can change; confirm the current scope and terms before rollout.
How we prepare and update field notesScope one evidence-backed review workflow.
Bring a redacted contract, payment packet and one unresolved question. Discuss the supported collection and follow-up steps, any additional scope and the human review needed to validate the result.
Start with the call, text or record your team already handles. Review the expected outcome and the human handoff before choosing a rollout.
Discuss your review workflow Explore the relevant capability
