If your organisation has been live on Workday for more than a year, your Advanced Compensation setup has probably been running quietly in the background since the day it was configured. Nobody opens it up to check it until the next review cycle forces the question, and by then the stakes are higher: managers are waiting on worksheets, Finance needs the budgets to hold, and employees are waiting to understand what they are actually getting and why.

This guide walks through what Workday Advanced Compensation actually covers, where organisations commonly run into trouble after go-live, and what a healthy setup looks like heading into your next review cycle. It is written for HR Directors, CFOs, CHROs and Heads of Enterprise Applications who inherited a configuration they did not build, or who built one years ago and have not had a reason to revisit it since, and who want a working picture of where to look before the next cycle, rather than a module-by-module manual.

Where it helps, we have linked out to deeper guides on specific areas: configuration, review cycles, pay equity, total rewards statements and manager readiness. Treat this as the map, and the linked guides as the detail.

What Is Workday Advanced Compensation?

It sits on top of core HCM data, jobs, organisations and workers, and adds the mechanics specific to compensation: plans, eligibility rules, budgets, worksheets, approval chains and statements.

In practice, the module covers four broad areas:

• Compensation plans and eligibility define who is in scope for merit, bonus, stock or allowance programmes, and under what conditions.
• Review cycles and budgets define how much money is available, how it is allocated down through the organisation, and how managers interact with worksheets to make award decisions.
• Approvals and security define who can see what, who signs off at each stage, and what gets logged for audit.
• Statements and reporting define how those decisions eventually reach the employee, and what Finance and HR can see in aggregate.

Each of these areas is configured once during implementation, and each one tends to assume the organisation it was built for. The trouble starts when the organisation changes, new entities, new currencies, new job architecture, new leadership, and the configuration does not change with it. Workday itself also changes twice a year through its release cycle, which is a second, quieter reason configuration can drift: new features and settings become available that nobody has gone back to evaluate against the original design.

Why Organisations Struggle With It After Go-Live

Compensation configuration rarely breaks in an obvious way. Nobody gets an error message when an eligibility rule is three reorganisations out of date, or when a review template nobody has opened since go-live quietly misroutes an approval. The symptoms show up elsewhere: a manager who cannot see the worksheet they are supposed to approve, a statement that does not match what was discussed in the calibration meeting, a Finance team reconciling awards against budget in a spreadsheet because the system total does not look right.

We see four patterns consistently across organisations twelve to thirty-six months post go-live:

1. Eligibility rules are built once at go-live and never revisited, even as job architecture and organisational structure change underneath them.
2. Ownership of the configuration sits unclearly between HR, Finance and IT, so nobody owns fixing it when something looks off.
3. Review templates and worksheets are not tested end to end until the cycle is already live, which means the first real test happens under time pressure.
4. Manual workarounds, usually a spreadsheet, quietly become the actual process, running alongside Workday rather than inside it.

None of this is a sign that Workday Advanced Compensation does not work. It is a sign that configuration needs periodic revisiting, the same way any other part of the system does. We go into more detail on each of these specific mistakes, and how to catch them early, in our guide to Workday Compensation Configuration Mistakes to Fix After Go-Live .

Signs Your Compensation Setup Needs a Review

Most organisations do not realise their compensation configuration needs attention until a cycle is already underway and something has gone visibly wrong. A few warning signs tend to show up earlier, if anyone is looking for them:

• Managers asking why they cannot see a worksheet they should be able to approve.
• HR fielding the same configuration question every cycle because nobody wrote down the answer last time.
• Finance maintaining a shadow spreadsheet to reconcile awards against budget because the system total has never quite matched.
• Statements going out with numbers that do not match the conversation a manager already had with their team.

None of these are dramatic on their own. Together, they are a reasonably reliable signal that the configuration has drifted further from the organisation it was built for than anyone has noticed, and that a structured review, rather than another cycle of working around the symptoms, is overdue.

Compensation Plans and Eligibility Rules

A compensation plan in Workday defines a specific type of award, merit, bonus, stock or allowance, and the rules that govern it: who is eligible, how the amount is calculated or guided, and how it flows into a review cycle. Most organisations run several plans at once, often layered, a merit plan plus a bonus plan plus, for some populations, a long-term incentive plan, each with its own eligibility logic.

Eligibility rules are where most configuration drift happens. A rule might be built around job profile, organisation, worker type, location or length of service, individually or in combination. At go-live, these rules are usually built to match the organisation as it existed at that moment. Over the following year or two, job architecture changes, new entities are added, new worker types appear, contractors, fixed-term staff, newly acquired teams, and the eligibility rules do not automatically keep up.

The practical risk is twofold. Workers who should be eligible for a plan get silently excluded, which usually surfaces as a manager escalation during the cycle. Or workers who should not be eligible get included, which usually surfaces much later, when Finance notices the numbers do not reconcile. Neither failure mode throws an error. Both are expensive to untangle mid cycle, and both are straightforward to catch with a structured review beforehand, ideally well before the review cycle opens rather than during it.

Review Cycles: Budgets, Guidelines and Worksheets

The review cycle is where compensation planning actually happens for managers. Workday supports budget pools set at whatever level makes sense, organisation, cost centre or manager, guideline matrices that suggest award ranges based on factors like performance rating and position in range, and worksheets where managers enter and justify their recommendations.

Two things tend to go wrong here. The first is budget and guideline configuration that was built for a prior cycle and not revisited: pools set against an organisational structure that has since changed, or guidelines that reference a performance rating scale the organisation has since replaced. The second is multicurrency complexity. Organisations running review cycles across multiple countries need a clear, agreed approach to exchange rates and local currency display, decided before the cycle opens, not debated mid cycle when a manager in one region cannot reconcile their pool against a manager in another.

Worksheets themselves are usually configured well at go-live and then left alone, which is mostly fine, but they are also the piece most worth testing end to end before each cycle, with real or realistic data, rather than assuming last year’s configuration still matches this year’s organisation. A short dry run with a handful of managers, ahead of the official launch, tends to surface the majority of issues that would otherwise appear as live tickets once the cycle is underway.

Approvals, Security and Audit Trail

Compensation decisions typically need to move through an approval chain, manager, HR partner, sometimes Finance, before they are finalised. Workday’s business process framework handles this, alongside security groups that control who can see which worksheets, budgets and statements.

The common failure mode here is not a broken approval chain, it is an approval chain nobody has reviewed since the organisation it was built for changed. A security group scoped to a management hierarchy that has since been reorganised can quietly give the wrong people visibility, or deny visibility to the right people, neither of which tends to get noticed until someone asks why a specific manager cannot see what they should.

Audit trail matters here too, for both compliance and for your own peace of mind. Workday logs who approved what and when, which is valuable during an actual compensation review, and increasingly valuable if pay equity reporting requires you to show your working.

It is worth checking this annually rather than assuming it still matches the organisation. Security groups built around a management hierarchy from two reorganisations ago do not throw an error when they stop matching reality, they simply grant or withhold visibility quietly, and the people affected rarely raise it as an issue until it becomes an obvious inconvenience during a live cycle.

Pay Equity and Compliance Considerations

Pay equity reporting starts with data, not with the report itself. Workday can support pay equity analysis well, but the output is only as reliable as the job architecture, worker data and compensation elements feeding into it. Inconsistent job grading, incomplete location or worker data, or compensation elements that are not mapped consistently across the organisation all undermine the analysis before it starts.

This matters more than it first appears. A pay equity analysis built on a job architecture where similar roles are graded inconsistently across business units will produce numbers that look precise but are not comparable, which is arguably worse than having no analysis at all, since it creates false confidence in a result that will not hold up to scrutiny. The same applies to compensation elements that are recorded inconsistently, a bonus that is captured as base pay in one region and as a separate element in another will distort any comparison between the two.

For UK organisations specifically, the build-up to a review cycle is a sensible time to check this data, not after the cycle has already run and decisions are locked in. That gives HR and Finance time to correct job grading inconsistencies or data gaps before they feed into the next round of pay decisions, rather than discovering them during reporting season when there is little room left to act. We cover the specific checks worth running in our guide to Workday Pay Equity Reporting: What UK Teams Should Prepare.

Total Rewards Statements and Employee Communication

However well a review cycle runs internally, most employees only ever see the outcome through a total rewards or compensation statement. If that statement is unclear, inconsistent with what their manager told them, or simply difficult to read, the quality of the underlying decision stops mattering, the communication becomes the story.

Getting this right means testing statements with real data before they go out, using plain language rather than internal plan codes, and making sure the numbers on the statement match the numbers in the conversation the manager actually had. We go into this in more depth in Total Rewards Statements in Workday: Setup, Testing and Employee Experience, and cover the manager side of that conversation in Preparing Managers for Compensation Conversations in Workday.

What Good Compensation Configuration Looks Like

A healthy Workday Compensation setup is not necessarily an elaborate one. In our experience, it is one where a small number of things are true at the same time:

• Eligibility rules are reviewed on a schedule, not just when something breaks, and someone specific is responsible for that review.
• Budget pools and guidelines are reconfirmed against the current organisation before each cycle opens, rather than inherited unchanged from the last one.
• Worksheets and review templates are tested with realistic data before managers see them live.
• Approval chains and security groups are checked against the current reporting structure, not the one that existed at go-live.
• Total rewards statements are tested for accuracy and read by someone outside the project team before they go out, since a statement that makes sense to the person who built it does not always make sense to the employee reading it.

None of this requires a major project. It requires a recurring habit, built into the calendar ahead of each cycle, rather than a one-off fix after something has already gone wrong.

A Readiness Checklist Before Your Next Review Cycle

A few hours spent checking the following before your next review cycle opens is consistently cheaper than the time spent untangling issues once managers are already working through their worksheets.

• Eligibility rules reviewed against current job architecture and entities
• Budget pools and guidelines reconfirmed against this cycle’s organisation
• Multicurrency approach agreed and documented before the cycle opens
• Worksheets tested end to end with realistic data
• Approval chains and security groups checked against current reporting lines
• Audit trail confirmed sufficient for pay equity and compliance needs
• Total rewards statements tested for accuracy and clarity
• Managers briefed and ready before statements go out