Annualized compensation planning: keeping EC aligned with Compensation Statements

[xavierlegarrec]

This blog was made as a reply to this question on another blog.

Introduction

When employees in an SAP SuccessFactors environment :

• have Pay Components in different frequencies (hourly, monthly, semi-monthly, annual) on their profile 
• yet annual Compensation planning is based on annualized values (see Option 2 here)
• and decimals are allowed for publish back of the new pay rate (no rounding applied to the new pay rate published back to EC)

slight annual salary value discrepancies (by a decimal point most of the time) between EC and Compensation worksheets can happen which can impact the consistency of communication to employees since Compensation Statements values can only be pulled from Compensation worksheets.

Example

• Pay Component value in EC = 3,500
• Units per year = 26 (frequency of the Pay Component)
• Pay Component Group value (curSalary in Compensation template) = 91,000  (3,500*26)
• Merit amount entered by planner in the Compensation worksheet = 9,000 / merit % is hence equal to ((100,000-91,000)/91,000)*100=9.8901 which rounds to 9.89%
• "Final Annualized Salary" standard column (finSalary) in the Comp worksheet now shows 100,000
• To publish to EC we need to divide 100,000 by the frequency used in the Pay Component which gives us 100,000/26=3,846.153846153846 --> 3,846.15 after half-up rounding (assuming two decimals)
• Once 3,846.15 is published back, the Pay Component Group in EC will (re)multiply it by 26 to get its value (and we cannot change this behavior) --> 3,846.15*26=99,999.9  the Annualized Salary in EC will show 99,999.9 whereas on the Compensation worksheets and on statements will show 100,000.

Here is the list of ideas I've explored that either fix this decimal point difference temporarily (meaning it will happen again in the following cycle) / or bring data consistency risks for the comp cycle, EC data or payroll replication : Removing decimals from the money format all together, hiding the EC Pay Component Group from employees in Comp Info while statements are out, playing with publish back dates, playing with Pay Component decimals (max 5), multiple Base Salary pay components with one excluded from pay roll replication, etc....

Proposed configuration adjustment with limited impact on the planner experience

Here is what I built for a customer a few years ago to always keep Statements and EC in sync yet keep decimals in what is published back:

1. Hide the amount from the standard merit column and only allow planners to enter a % (a specific section with custom columns can be created to allow planners to find the right percentage based on an amount if needed)
2. Apply the merit % entered by planners NOT to the Annualized Salary column (curSalary) BUT to the Pay Component value we brought from EC into a custom column using the configuration below (assuming that as per leading practices there is at least one Pay Component for each employee that has the setting : Use for Comp = Comp or Use for Comp = Both)

1. We now have a first standard column Merit % (editable) then another read-only custom column Merit Amount where the formula is: customCurrentPayRate*(merit/curSalary)
2. Finally add two columns :
   • Final Pay Rate: customCurrentPayRate+customMeritAmount (will be used for publish back)
   • Final Annualized Salary: customFinalPayRate*26

As mentioned in the introduction a common design used by customers (but with a higher impact on the planner experience in the sense that the sum of current pay + their recommendation is different by a few decimals from what gets published back to EC) is to keep the standard merit column behavior with both % and amount editable and to simply have two columns in the "Final" group of columns that are applying rounding : 

• "Final Adjusted Pay Rate" where decimals are removed through rounding (see this blog for more information on removing decimals using custom rounding). This value is also to be used for publish back.
• "Final Adjusted Annual Salary" which multiplies the Final Adjusted Pay Rate by the Pay Component frequency.

All the best

Xavier

(If you found this blog useful please consider giving it a Like)