My rule is to fix data at the source when the issue reflects incorrect business logic or broken data contracts, and use transformations when the change is intentional and specific to a downstream use case.

For example, if an upstream system repeatedly sends invalid customer IDs or inconsistent status codes, fixing it in every ETL pipeline just creates multiple points of failure. The same defect can surface in a new dashboard, model, or downstream consumer that doesn’t have that workaround.

However, transformations are still necessary for legitimate differences in representation, schema mapping, and analytical requirements. Not every inconsistency is a source-level defect.

If the source team cannot make changes, I’d isolate the correction in a shared, version-controlled transformation layer rather than duplicating patches across pipelines. I’d also add data quality tests, monitor exception rates, and document the workaround with a clear owner.

One important distinction: a transformation can make bad data usable, but it doesn’t necessarily make the underlying system reliable. The goal should be to prevent recurring defects wherever possible, while keeping unavoidable corrections explicit, testable, and observable.