Consistency Validation
Check that related fields agree before one row tells two different stories and the report starts looking shifty.
Consistency validation checks that related fields contain logically consistent values and do not conflict with one another. Advanced ETL Processor runs these checks inside a visual ETL workflow, routes inconsistent rows, logs failed business rules, and keeps the original source data unchanged.
Consistency validation catches fields that disagree
A value can be present, correctly formatted, and still wrong because another field says something different. That is the awkward part of data quality. The row looks tidy until the business rule taps it on the shoulder.
Consistency validation compares related fields in the same record or workflow context. If the values contradict each other, the workflow rejects the row, logs the issue, or routes it for review before loading.
The hotel date rule is a simple consistency check
The rule is direct: the hotel departure date must be after the arrival date. Both fields may contain valid dates, but the combination still fails when the dates disagree.
Valid stay
Arrival Date: 10 July 2026. Departure Date: 15 July 2026. The departure date is after the arrival date, so the record continues.
Invalid stay
Arrival Date: 10 July 2026. Departure Date: 8 July 2026. The guest appears to have checked out before arriving, which is impressive but not useful data.
Business rules turn consistency checks into decisions
Consistency validation works best when the rule is written in plain business language first. For the hotel example, that rule is: departure date must be after arrival date.
Once the rule is clear, the ETL workflow tests it the same way every time. That matters for scheduled imports, booking feeds, finance data, stock movements, and any process where two related values must agree before the row is trusted.
Dates
End date must be after start date. Delivery date must not be before order date.
Amounts
Paid amount must not exceed invoice total unless the business allows overpayments.
Status fields
A completed order needs a completion date. A cancelled order must not look active.
Reference values
Country, currency, tax code, and customer type need to make sense together.
Route inconsistent rows instead of guessing
The safest pattern separates inconsistent rows from clean rows. Advanced ETL Processor keeps the original source unchanged and records exactly which rule failed.
Do not automatically swap dates, change statuses, or invent missing values unless the business has approved that correction. Guessing is not validation. It is fortune-telling with a database connection.
Related guides include date format validation, range validation, and creating complex data validation rules.
When consistency validation is not worth automating
If you have a small one-off spreadsheet with ten rows, a quick manual review may be enough. Do not build a full workflow where a simple sort and filter will solve the problem.
Automate consistency validation when the feed runs repeatedly, the rule protects reports or customers, or a bad combination could create expensive cleanup later. That is where repeatable validation earns its keep.
Video
Consistency validation questions
What is consistency validation in ETL?
Consistency validation checks whether related fields make sense together. It catches values that may be valid on their own but conflict with another value in the same record.
What is an example of consistency validation?
A hotel departure date must be after the arrival date. Arrival Date 10 July 2026 and Departure Date 15 July 2026 is valid. Arrival Date 10 July 2026 and Departure Date 8 July 2026 is invalid.
How is consistency validation different from range validation?
Range validation checks whether one value sits inside allowed limits. Consistency validation compares related fields, such as start and end dates, debit and credit values, or status and completion date.
Should consistency errors be fixed automatically?
Only when the correction rule is approved and safe. In most cases, route inconsistent rows to an exception path so the source record can be reviewed without changing the original data.
Check the business rule before the load
Use Advanced ETL Processor to define the related fields, test the rule in a repeatable workflow, and route inconsistent rows clearly. Clean data is much easier when the rows stop arguing with themselves.
A valid field is not enough. The whole row has to make sense.