The Real Cost of Bad HR Data (And What To Do About It)

Most bad HR data was entered correctly.

That sounds wrong, and it's the reason data quality work usually fails. The mental image is a typo, a fat-fingered date, someone rushing through a hire. Those exist and they're the easiest category to fix. They're also a small share of what's actually wrong in a mature tenant.

The expensive version is a field populated exactly as the person intended, by someone who understood the process, using a value that was correct for their purpose. Nothing errored. No validation rule would have caught it. And it's still wrong somewhere else, because two functions were never using the same definition, or because something downstream started depending on that field after the decision was made.

A Decision Made Without the Other Function in the Room

Position control is an organizational discipline, not a system feature. Finance needs to know what positions exist, which are funded and for how long, what's approved but unfilled, and what's currently being recruited against which budget line. Every organization needs some version of that answer whether or not they run Workday.

Workday supports it through the staffing model, which is set per supervisory organization and gets chosen during implementation. Position management creates a discrete position object that has to be created and approved before anyone can be hired into it. Job management skips that layer and lets you hire directly against a job profile within the supervisory org.

Both are legitimate. Job management is faster and carries less administrative overhead, which makes it a reasonable choice for high-turnover hourly populations. Position management gives you the object Finance wants to plan against.

The problem is who makes that call. It usually gets decided during design sessions on HR's criteria: how much maintenance is this, how fast can we hire, how many approvals do we want. Those are the right questions for HR to ask, and Finance is frequently not in the room.

Then a year after go-live somebody in FP&A asks to see open headcount against budget, and depending on a decision made in a workshop nobody remembers, that report either exists or it doesn't. Nothing was entered incorrectly. A configuration choice made on one function's criteria determined whether another function could answer its own questions, and switching afterward is close to a reimplementation.

This is the shape worth recognizing, because it doesn't look like a data problem from inside either function. It only appears when the two sets of expectations meet.

The Version That Costs Money

A job profile gets associated with a job family. From HR's side, job family is job architecture: career framework, leveling, how roles group together. The assignment is correct by that definition.

Then shift differential eligibility gets keyed to job family, and nobody tells HR that their architecture field now carries a payroll consequence. HR keeps making the same reasonable decisions they've always made, and a group of workers starts receiving a differential they were never entitled to.

From the HR side everything still looks correct. It surfaces in payroll as leakage, after the money is out the door, and the correction runs backward against people who did nothing wrong.

The failure wasn't the entry. It was that a field acquired a second meaning and the people populating it were never told.

Where It Actually Comes From

Three sources, in roughly the order they matter.

Fields with more than one definition

Two functions populate or read the same field with different intent. Both are internally consistent. Neither is wrong from where they sit. The report that combines them is what breaks, and it breaks quietly, because the output still looks like a number.

Dependencies added after the fact

Something downstream starts keying off a field that already existed. Eligibility rules, costing allocations, integrations, and security all do this. The people maintaining the field find out when something goes wrong.

Conversion debt

Data moved during implementation without a full audit, accepted on the basis that it would be cleaned up later. Later rarely comes, and every report and integration built afterward inherits it.

Traditional data entry error is real, and it's fourth on this list.

What It Costs

The cost is hard to total precisely because it spreads across functions that don't compare notes.

Payroll

Position and compensation inaccuracies produce payroll output that reflects them. At a few thousand employees, small per-worker errors compound into real dollars every cycle, and the correction work costs more than the error did.

Compliance

Regulatory audits, benefits eligibility, ACA reporting, and EEO data all trace back to HR data quality. A single audit finding can cost more than a year of governance work, and remediating under an auditor's timeline is the most expensive way to do it.

Workforce decisions

When headcount or position data is wrong, leaders make hiring, restructuring, and resource decisions against a picture of the organization that doesn't exist. Those decisions have long timelines, and by the time the error surfaces, three more have been built on top of it.

The third one is the largest and the least visible, because nobody attributes a bad decision to a bad number six months after the fact.

Start With the Baseline

Most data quality work starts with worker records, which is starting in the middle.

Look at foundation data first. Job profiles and everything attached to them, including job family, job family group, grade, and grade profile. Cost centers. Compensation plans and their eligibility rules. Location addresses. Worker type and employee type.

Everything else is built on top of that layer. Who's eligible for which compensation plan, who's in scope for time tracking and time off, who's classified exempt or non-exempt, how costing flows, what a manager can see. All of it resolves through foundation data.

An error in a worker record affects one person. An error in the foundation affects everyone who touches it, and it keeps affecting people you hire next year. Cleaning worker records on top of a foundation nobody has audited means doing the work twice.

Once the foundation is established, sort what you find into two piles. Records that are wrong, and definitions that are ambiguous. The first is a cleanup project with a finish line. The second is a governance problem, and correcting records without settling the definition means running the same cleanup again next year.

What Configuration Can and Can't Do

Workday's validation options are underused in most post-go-live tenants. Conditional prompts, required fields, and validation rules catch broad categories of error at entry rather than in a report six months later. These are low-effort changes with a high return, and they go unbuilt because nobody owns the request.

They aren't the whole answer, and it's worth being honest about where they stop.

A validation rule can't know that job family is going to be used for eligibility. It can't reconcile HR's definition of a position with Finance's. And when a rule gets built because one team keeps entering things a particular way, what's actually happened is that the system was configured to avoid a conversation about a pattern on that team. That works, in the sense that the bad data stops. The behavior doesn't change, and it shows up somewhere else.

Configuration is the right tool for errors. It's the wrong tool for disagreements and for behavior.

Prevention Is a Governance Question

Remediation fixes what's broken. Governance decides what the fields mean.

A working framework answers four things per field: what it means, who's authorized to change it, what values are acceptable, and what depends on it downstream. The fourth is the one organizations skip, and it's the one that would have caught the job family decision before it reached payroll.

Assign stewards by domain rather than by system. The person who owns compensation data should own it whether it's changing through a hire, a job change, or a mass update, because the risk travels with the data rather than with the transaction.

Then put a review cadence on it. Scheduled reports that flag anomalies give drift somewhere to surface before it compounds.

How CRG Approaches This

We start at the foundation and we start by asking whether the problem is records or definitions, because those need different work and organizations usually assume it's the first one.

The measure of a finished engagement is whether your team can say what a field means and what depends on it, without calling us.

Talk to CRG about what your data is actually costing you.