22 Data Quality Checks Every Data Engineer Should Know

A practical reference for checks that catch bad data before it reaches reporting, automation, or customers.

Advanced ETL Processor
4.9 ★★★★★ Based on 16 reviews on Capterra See all reviews on Capterra →

These 22 data quality checks cover the problems data engineers see most often: missing values, duplicates, broken relationships, schema drift, late feeds, and totals that have gone wandering without a map.

Data quality issues examples in Advanced ETL Processor validation

Use the checks that match the risk

Not every workflow needs all 22 checks. A one-off file may need only required fields and data types. A nightly finance feed should probably check keys, totals, volume, freshness, and audit columns before anyone trusts the output.

Rule of thumb: if a bad value can reach a customer, a finance report, or an automated decision, validate it before loading. If it only annoys a temporary spreadsheet, make tea and keep the rule simple.

22 data quality checks explained

Check What it is Why it matters Typical action
Allowed values or domain validation Checks that a value belongs to an approved list, such as status, currency, country, department, or product category. Unexpected values split reporting groups and break downstream rules. `Completed`, `Complete`, and `COMP` are three arguments waiting to happen. Use reference tables, map known aliases, reject unknown values, and report new values for approval.
Audit column consistency checks Checks audit fields such as created date, updated date, created by, updated by, batch ID, and source system. Audit fields explain where data came from and when it changed. Without them, troubleshooting becomes archaeology. Require audit columns on critical feeds, validate timestamps, and ensure batch identifiers match the current run.
Business rule consistency for aggregates and totals Checks that business-specific totals and calculated values agree with source values or expected formulas. Header totals, line totals, tax totals, and balances must agree. If they do not, the data may be technically valid but financially useless. Compare calculated totals, allow agreed rounding tolerance, and quarantine records that fail.
Completeness check for expected partitions or files Verifies that all expected files, partitions, regions, dates, or batches are present before processing. Processing 11 monthly files out of 12 produces neat-looking but wrong results. That is the worst kind of wrong. Check the expected manifest, file count, partition list, or control table before loading.
Cross-column consistency checks Compares values across fields in the same row to confirm they make sense together. A shipped date before an order date, a closed case with no close date, or a UK postcode with a US country code usually means the row needs attention. Define field-pair rules, log violations with both values, and fix the source or transformation rule.
Data type validation against schema Compares field values with expected schema types such as date, integer, decimal, boolean, and text. One text value in a numeric field can stop an import or force bad type conversion. Excel is particularly talented at this form of mischief. Reject invalid values, convert safe values explicitly, or update the schema if the source contract has genuinely changed.
Distribution checks for mean, median, and standard deviation Compares statistical shape against historical behaviour or expected data profiles. Row counts can look normal while values have shifted. Distribution checks catch silent changes in pricing, quantities, durations, and measurements. Profile key numeric fields and alert when the distribution moves beyond an agreed tolerance.
Duplicate file ingestion across systems Checks whether the same file, batch, or extract has already been processed. Duplicate ingestion creates repeated transactions and inflated totals, especially when multiple systems share folders or feeds. Track file names, checksums, batch IDs, and processed timestamps before accepting a file.
Duplicate record detection Finds repeated records using exact matches or business keys such as customer, date, amount, and reference number. Duplicates inflate totals, create false activity, and make reconciliation feel like a hobby nobody asked for. Deduplicate by rule, keep the newest record, quarantine both copies, or flag them for manual review.
Hierarchy validation for region, country, and state Verifies that hierarchical values belong together, such as state within country or department within division. Bad hierarchy values distort rollups and regional reporting. They also make drill-down dashboards deeply irritating. Validate against hierarchy reference tables and reject or map invalid combinations.
Negative value checks where not allowed Confirms that values such as quantity, stock count, payment amount, or hours are not negative unless the business permits it. Negative values may be legitimate credits or returns, but they may also be source errors. The rule depends on the field. Define where negatives are allowed, reject the rest, and document exceptions such as refunds and adjustments.
Null or missing values check Confirms that required fields are populated and that blanks, nulls, empty strings, and placeholder values are handled consistently. Missing values can break joins, calculations, exports, and reports. They also hide source-system problems until someone asks why half a dashboard is empty. Reject the row, apply an agreed default, route it to an exception table, or ask the source owner to fix the feed.
Numeric range checks, such as 0-100% Confirms that numeric values sit inside agreed limits, such as percentages between 0 and 100 or quantities above zero. A value can be numeric and still be wrong. Range checks catch values that pass type validation but fail common sense. Set lower and upper limits, log failures, and review thresholds regularly with the business owner.
Outlier detection for abnormal values Identifies values far outside normal behaviour, even when they pass basic type and range checks. Outliers can be valid, but they can also reveal unit errors, decimal-point mistakes, and source-system defects. Flag outliers for review, route them to exceptions, or require approval before publishing.
Percentage or total consistency checks Checks that percentages add to expected totals and that component values match summary values. Percentages that add to 103% make reports look exciting for all the wrong reasons. Use tolerance rules for rounding, compare components with totals, and report mismatches.
Primary key uniqueness check Verifies that each primary key appears once in the dataset or target load batch. Primary keys identify records. If they are duplicated, updates become unpredictable and downstream systems may overwrite the wrong row. Stop the load, isolate duplicate keys, and decide whether the source should merge, reject, or reissue the records.
Referential integrity validation Checks that child records have valid parent records, such as orders linked to customers or invoice lines linked to invoice headers. Broken relationships create orphan records and unreliable reporting. Databases can reject them, but ETL-side checks usually give cleaner diagnostics. Load parents first, reject unmatched children, or send unmatched records to an exception workflow.
Regex pattern validation for email, phone, and IDs Uses a regular expression to verify that values match a required format. Pattern checks catch malformed email addresses, phone numbers, IDs, postcodes, and codes before they enter operational systems. Apply a documented pattern, reject invalid values, and keep patterns maintainable rather than heroic.
Schema drift detection for new or removed columns Detects changes in column names, order, count, data types, or nested structure. Schema drift breaks mappings and transformations. It usually arrives quietly, like a cat, but with more support tickets. Compare incoming schema with the expected schema and fail fast when required fields change.
String length validation Checks that text values fit target field sizes before loading. Oversized strings can fail inserts or get truncated. Truncated account codes are a small disaster wearing a short coat. Reject, trim only when approved, expand the target field, or route long values for review.
Timeliness or freshness check against SLA Confirms that files, records, or extracts arrive within the expected time window. Old data can be worse than no data because people trust it. A stale dashboard is just a confident liar with charts. Compare extract timestamps with the SLA, alert on late feeds, and stop dependent workflows when freshness is critical.
Volume checks against historical thresholds Compares current row counts or file sizes with previous runs or expected ranges. A sudden drop or spike often indicates an upstream failure, duplicate extraction, or changed filter. Set warning and failure thresholds, compare against history, and review exceptions before loading.

Where Advanced ETL Processor fits

Advanced ETL Processor Enterprise can run these checks inside a visual ETL workflow, log failures, route rejected rows, and keep the original files unchanged. That matters when the process is scheduled and nobody is watching the screen at 2:00 a.m.

The Validator object is the main place to configure these rules. The validation rules documentation lists the available checks before you start wiring them into a workflow.

Useful next pages include required field validation, range validation, lookup validation, and referential integrity validation.

Video

Next steps

If this validation rule belongs in a repeatable ETL process, configure it in the Validator object, test it on a sample file, then decide whether failed rows should be rejected, logged, or routed for review.

Keep the original data unchanged. Raw files are still the witness statement.