A useful audit connects every reported result to a defined indicator, an authorised data source, a documented quality rule and a review decision. It should reveal material risk without turning unusual records into unsupported accusations.
1. Start with the reporting decision—not the spreadsheet
List the programme questions, donor indicators and management decisions the dataset is expected to support. Then identify the questionnaire fields, calculations and reporting tables behind each one. This prevents a technically tidy audit that misses the measures that actually matter.
Record the review period, data owner, collection platform, form version, responsible reviewers and the exact files in scope. If an indicator cannot be traced back to a source field and definition, flag the gap before calculating it.
- Indicator definition and numerator/denominator
- Data source and deployed form version
- Reporting period and inclusion rules
- Named owner, analyst and approver
2. Check structure, completeness and coding
Confirm that one row represents the intended unit, identifiers are unique where required, dates parse consistently and categorical values match the deployed choice list. Review missingness by variable, site, enumerator and time period because an acceptable overall rate can hide a serious local gap.
Separate blanks that are valid because of skip logic from fields that should have been completed. Keep missing, not applicable, refused and unknown as distinct states when the programme needs that distinction.
- Duplicate or reused record IDs
- Required-field missingness
- Invalid choice codes
- Date and number formats
- Broken repeat-group relationships
3. Test ranges, skip logic and cross-field consistency
Range checks should reflect the instrument and programme context, not convenient generic limits. Cross-field rules are often more informative: an interview date should fit the reporting window, an age category should agree with age, and a follow-up answer should only appear when its parent question triggered it.
Document each rule, its rationale, severity and recommended response. That makes the review reproducible and helps the field team improve the form instead of repeatedly fixing the same export problem.
- Impossible or out-of-scope values
- Contradictory responses
- Unexpected answers after a skipped question
- Indicator totals that do not reconcile
- Outliers requiring programme context
4. Review fieldwork signals carefully
Interview duration, submission timing, repeated response patterns, device metadata and GPS can help a team prioritise records for review. None of these signals proves fraud on its own. Network conditions, shared devices, dense facilities, form design and legitimate repeated measurements can create similar patterns.
Use thresholds agreed with the programme, retain the evidence behind each flag and require a human reviewer to record the final decision. If location was not collected lawfully or is unnecessary for the stated purpose, do not introduce it later simply because it is available.
- Very short or unusually long interviews
- Large clusters of identical responses
- Repeated or low-accuracy coordinates
- Implausible travel or submission sequences
- Human review outcome and reason
5. Protect participants and preserve an audit trail
Use the minimum data necessary for the audit. Remove direct identifiers where possible, keep uploads private, isolate projects between organisations and restrict access by role. Public reports should contain de-identified summaries rather than participant names, phone numbers, national IDs or precise household locations.
Preserve an untouched raw version and apply approved corrections to a separate working copy. Record who uploaded, reviewed, approved, exported or deleted the data; set a retention period; and provide a delete-now control when the controller requests it.
- Consent or lawful-purpose confirmation
- Owner, Analyst and Client permissions
- Raw-versus-working dataset separation
- Cleaning decision log
- Retention and secure deletion plan
6. Close with decisions, not a pile of flags
Prioritise issues by their effect on the programme decision: blocking, material, review or informational. State what was corrected, what remains unresolved and whether each planned analysis or indicator is safe to use.
The final package should include an issue register, cleaning log, analysis-ready dataset, data dictionary and short management summary. Preliminary analysis must remain clearly labelled until an analyst validates the methods, assumptions and output against the approved dataset version.
NGO data quality audit in Kenya
We can review your actual form, dataset and reporting requirement, then scope the smallest service that solves the risk.
Explore the service ↗