ipacheck and Stata high-frequency checks compared with DataFlow

Most research teams that run high-frequency checks, the daily data quality checks run while fieldwork is going on, write them in Stata. Two open-source packages give them a head start: Innovations for Poverty Action's ipacheck and ARCED Foundation's arceddataflow, the Stata workflow DataFlow grew out of. This page sets out what each does, when do-files are the right tool, and what changes when the same checks run in an app.

What ipacheck does

The ipacheck README describes it as IPA's Stata package for running high-frequency checks during data collection. ipacheck new creates a project folder with a master do-file, a globals do-file, a prep do-file and Excel input sheets, where you set which variables each check looks at. The checks write their results to formatted Excel workbooks to share with field teams. It is released under the MIT licence.

* Install, update and start a project (from the ipacheck README)
net install ipacheck, all replace from("https://raw.githubusercontent.com/PovertyAction/high-frequency-checks/master")
ipacheck update
ipacheck new, surveys("household") folder("C:/projects/hh_survey")

The README lists these programs:

That is a thorough set, maintained in the open on GitHub, and free for anyone with Stata. Several of the programs read SurveyCTO's own outputs, such as text audits and comments, which suits teams collecting on SurveyCTO.

arceddataflow, ARCED Foundation's Stata workflow

arceddataflow is ARCED Foundation's open-source Stata command (MIT licence, version 1.0.0 from May 2023). Its README describes it as a command that creates the do-files for a project's data flow. Its checks do-file, 04_checks.do, writes numbered checks to the sheets of an Excel workbook: progress by date and by enumerator, duplicate IDs among consented interviews, form versions, refusals, start and end dates, outliers beyond the mean plus or minus a set number of standard deviations, missing answers, comments, and time spent per question from text audits.

DataFlow is built on arceddataflow's ideas, and arceddataflow stays open source. DataFlow's way of handling corrections follows arceddataflow's corrections-sheet approach: the raw data is never changed, and the clean data is the raw data with the corrections applied on top.

When Stata do-files are the right choice

• Someone on the team writes and maintains Stata code, and will be there for the whole of fieldwork.
• The checks are unusual for your survey: a panel matched to last round, a sampling rule, a check that needs a regression. Anything you can write in Stata, you can check.
• Cleaning, construction and analysis are already in Stata, and the do-files are what the replication package will hold.
• The project's data rules allow only approved software on the computer that holds the data, and Stata is on the list.
• The budget is nothing beyond the Stata licence you already have.

In those cases, ipacheck or arceddataflow, run well, does the job. The cost is the time around the code: filling in input sheets for each survey, remembering to run the master do-file each day, keeping it working when the form changes mid-survey, and turning what the field team says about each flag into lines in the corrections file. When the person who wrote the code leaves, someone else has to learn it mid-survey.

When an app fits better

• Nobody on the team writes Stata, or the one person who does is needed for analysis, and the alternative is a spreadsheet (see data cleaning in Excel for where that breaks).
• Several surveys run at once, each with its own form, and the checks have to be ready on the first day of data.
• Supervisors need a list of flags with the interview, the question and the recorded value, and their answers have to come back as logged corrections rather than notes in an email.
• The client wants to see progress and how each problem was handled, without being sent the data.
• Names, phone numbers and GPS points have to stay out of the files the team works on and shares.

Side by side

Keeping both

Plenty of teams will keep their do-files and add DataFlow, or the other way round. A few rules keep that tidy:

• Decide where corrections live. Either in DataFlow or in your corrections do-file, not both. Two places for corrections leave a dataset no single record explains.
• Feed your analysis do-files from DataFlow's download. The .dta has labels from the form, multi-select answers as 0/1 variables and don't-know codes as Stata extended missing values, and it comes with the do-file that rebuilds it.
• Match the rules where it matters. If your Stata code flags outliers by mean and standard deviations, set DataFlow's outlier checks to the same method and number, and compare the flags in the first week. Outliers in survey data explains how the two methods differ.
• Keep project-specific checks in Stata if you like. Run them on DataFlow's de-identified download, so the personal data stays in one place.

Every DataFlow download includes corrections.csv, the full correction log, which reads straight into Stata for a summary or a merge:

* DataFlow's correction log: who corrected which variables
import delimited using "corrections.csv", varnames(1) stringcols(_all) clear
keep if status == "active"
tab variable corrected_by
list interview variable old_value new_value reason if variable == "income_monthly", noobs

How DataFlow runs high-frequency checks

Set up from the form

When you add the XLSForm and the data, DataFlow adds the checks itself, and keeps adding them on each sync as they start to apply. Among them: duplicates on ID variables; interview length under 40% of the median or 5 minutes, whichever is longer, or over 3 times the median; ranges from the form's constraints; outliers beyond 3 interquartile ranges; interviews where more than 20% of answers are don't know or refused; and, as ipacheck and DIME's iehfc check them, skip logic, the form's constraints that aren't simple ranges, and the same answer all the way down a rating scale. A suggested check that would flag more than 5% of interviews starts switched off, unless at least half of its flags come from one enumerator. Every check can be opened and changed, and the outlier method switched to mean and standard deviations, the rule arceddataflow and most Stata check code use.

Runs on every sync

Each sync adds the new interviews, adds any checks they now call for, and runs the checks. Syncs can run on a timetable you switch on, every 2 hours from 7:00 to 22:00 unless you change it, while the app is open and, on Windows and macOS, through the system's own scheduler while it isn't. Nobody has to remember to run the master do-file.

A log you can undo

The raw submissions are never modified; the clean data is rebuilt from them plus the corrections still in effect. A correction can't be saved without a reason, and it records the old and new value, who made it and when. Any correction can be undone, and so can a change to many interviews at once, as a whole. Every action goes into an activity log where each entry carries a hash of the one before, so editing past entries breaks the chain.

The do-file is still there

A download gives the data as Stata .dta (format 118, read by Stata 14 and later), CSV, Excel or R. With the do-file option, on by default, it also holds raw.csv, the submissions as received before any correction, and dataflow.do, which rebuilds the dataset from it. The do-file merges in each interview's status, replays every correction still in effect, oldest first, with its reason, who and the date, then splits multi-select answers, converts numbers, applies your recodes, derived variables, drops and renames, turns don't-know and refused codes into extended missing values and adds the labels. Repeat-group tables are written by DataFlow and aren't rebuilt by the do-file. A shortened example:

* Household survey: rebuild the prepared dataset from raw.csv
* Made by DataFlow on 2026-11-07 09:30 UTC. raw.csv holds the submissions before any correction.
* Repeat-group tables are written by DataFlow and aren't rebuilt here.

version 14
clear all
set more off
import delimited using "raw.csv", varnames(1) stringcols(_all) bindquote(strict) maxquotedrows(unlimited) clear

* Interview status from DataFlow (1 Clean, 2 Checked, 3 Needs a look, 4 Set aside)
* (status.csv is merged in here)

* Corrections from the DataFlow log
replace income_monthly = "6000" if KEY == "uuid:7c1e"  // Extra zero, confirmed by the supervisor (amina, 2026-11-05)
replace hhsize = "5" if KEY == "uuid:a4d2"  // Roster lists 5 members (amina, 2026-11-06)

* Don't know, refused and similar codes as Stata missing values
mvdecode _all, mv(-999=.d \ -888=.r)

save "data.dta", replace

The download can leave out interviews that still need a look or were set aside, and the do-file then keeps only the clean and checked ones. Personal data stays out of the download, raw.csv included, unless someone unlocks it for that download, which is logged.

The same flags as arceddataflow

DataFlow's code includes a test that runs arceddataflow's duplicate and outlier logic in Stata on the sample survey, and checks that DataFlow, set to the same rules (mean ± 3 standard deviations, don't-know codes left out), flags exactly the same interviews, check by check across eight numeric variables and the household ID. A second test computes the same rules by hand, so the formulas are checked on every run. The two rules, as the test runs them in Stata:

* Check 3: repeated IDs among consented interviews
preserve
keep if consent == 1
duplicates tag hhid, generate(dup)
list key hhid if dup > 0
restore

* Check 7: outliers beyond the mean ± 3 standard deviations
* (don't-know and refused codes -999 and -888 set to missing first)
quietly summarize income_monthly
generate byte outlier = (income_monthly > r(mean) + 3*r(sd) | income_monthly < r(mean) - 3*r(sd)) & !missing(income_monthly)
list key income_monthly if outlier == 1

In DataFlow the first is a duplicate check on hhid, and the second an outlier check with the method set to standard deviations, 3 of them, ignoring -999 and -888. Both run again on every sync.

Beyond the do-files

Back-checks are modelled on ipabcstats: questions that shouldn't change, questions that test the enumerator's skill, and questions that may change within a tolerance, with differences counted per enumerator, per back-checker and per question. Six statistical signs of made-up interviews are computed for each enumerator with at least 10 interviews, once at least four enumerators have that many. DataFlow connects to SurveyLoopr, SurveyCTO, ODK Central and KoboToolbox, and imports CSV or Excel exports from any other tool. For the checks themselves as an openly licensed checklist, see the Field Data Quality Standard.

Questions