As a professionally certified SuccessFactors Compensation consultant, I would like to share some of my experience regarding compensation statements. Hopefully, this blog will provide answers to questions you may have about the process, helping to simplify your experience and deliver the best statements possible to your employees.
Typically, employees are so busy designing their worksheets that they forget about the statements until the last minute. The most important question to ask while you are still designing your worksheet is, which fields do I need on my statement? Including these fields in your template ensures that statement creation is seamless.
Below is a checklist of 10 important items to consider before you start creating compensation statements.
1. Type of Statement
Different types of statements are available for Compensation and Variable Pay. You will need to decide what types of statement work best for you.
Type 1: Standard Personal Compensation Statement with a company logo, title, letter text, and compensation fields in a group to the right of the text. This statement includes elements from the Compensation Plan only.
Type 2: Standard Personal Variable Pay Statement with a company logo, title, letter text, and variable pay fields in multiple groups to the right of the text. This statement includes elements from the Variable Pay Plan only.
Type 3: Combined Statement with a company logo, title, letter text, and variable pay fields in multiple groups to the right of the text. This statement includes elements from both the Compensation and Variable Pay plans in one statement.
2. Standard vs. Custom
You can download templates from the SuccessStore. To access the SuccessStore – from within the SucessFactors Application:
- Go to Admin Center
- Compensation
- Actions for all plans
- Manage Statement Templates
- Add Template
- Select from SuccessStore
In the following diagram you can see an example of what is available for Personal Compensation Statements.
Similarly, you can import Combined and Variable Pay statements form the SuccessStore.
You will have the option to customize the statement text and the block on the right, as shown below. You can insert additional blocks, define the heading, and select the fields that you would like to display in each block.
The standard look and feel and will typically look something like this:
You can also design your own layout. You will need someone with XML/XSL skills to assist you with this effort. Make sure that you ask about custom statements when you discuss the Statement of Work (SOW), as this may be a change order depending on the amount of work that will be required. Typical SOWs include only standard look-and-feel statements as described above.
The following is an example of a custom statement:
3. Statement Fields
Make sure that all fields required for the statement are defined in your templates. For example, Merit %, while displaying on the worksheet, is not a field that is available to print on a statement; if that is something that you would like to show on the statement, you will need to define a separate custom formula field. Make sure that all statement fields are included in the worksheet.
It is common practice to add fields only used for statements to the end of the worksheet as HIDDEN fields. Keep in mind that you do not want to duplicate fields, so if it was already defined in your worksheet, you do not have to define a separate field specific for statements; use what you already have, as shown below.
4. Number of Statements
I am often asked whether separate statements are required if some people have a Lump Sum and others don’t; some people have a Merit and others don’t.
You do not need separate statements. There are “formulas” that you can use in SuccessFactors that will only display a field if certain criteria are met. For example, only display Lump Sum if the Lump Sum value is greater than 0, as shown below.
You will need a separate statement if the wording/message of the statement is different. You will need a separate statement for each language.
Define as many statements as you need for a plan. Read the SOW carefully to ensure that the number of statements that you require is specifically called out.
I have seen customers use only one XML to produce different statements in multiple languages. This is custom and can only be accomplished using XML/XSL coding. The risk with this method is that if you make a change to one statement, it could potentially break something in a different statement.
5. Statement Groups
You can group employees into statement groups and print different statements based on the groups.
For example, if employees in the United States need a different statement than the employees in the United Kingdom, and the United Kingdom needs a different statement than all other employees:
- Create a dynamic group for United States Employees: Country Code = US
- Create a dynamic group for United Kingdom Employees: Country Code = UK
- Create three statements: one for US, one for UK, and one default for everyone else.
The following screen-print is an example of the two statement groups (first and second bullets above) that we create and the number of employees in each group:
You can define groups to be dynamic (preferred):
Or you can manually assign users to groups, as shown below. Use this method only when you cannot define the group dynamically. Manually assigned groups should be continually monitored to ensure that the people within the group are still relevant.
Statement groups can also be used to generate statements at different times for different groups of employees. For example, if statements are needed for China before they are needed for the rest of the world, you can create a group for China. You can assign the same statement to multiple groups with different visibility settings for each group. In other words, you can make the statements available to the employees in China before you make them available to the employees in the rest of the world using the statement permission (discussed in the following section).
6. Visibility/Distribution
The compensation administrator has the ability to create default permissions for each statement, as shown below. This can be overwritten at the compensation template level and different for each group and statement combination attached to the template.
7. Testing and Validation
It is important to test each statement thoroughly; allow enough time to test statements once the worksheets have been finalized. Keep in mind that statements are often tested while your worksheets are rolled out to managers, so you may run out of time to test if you don’t plan this out correctly. If you wait until the templates are rolled out, you no longer have the ability to make changes or add fields that are required for the compensation statements.
If you test the statements and your worksheets at the same time, you can move them to production at the same time, and you can validate and correct any errors prior to rolling out worksheets to your compensation planners.
Keep a running list of test scenarios to ensure that you validate that the correct statements are generated and the corrected data is displayed on each type of statement. For example, if there are different elements printed in the header for a promotion for China than a promotion in the US, then (1) make sure that the statement does not print for the US and (2) make sure that it does print for China.
Always include negative testing scenarios also.
8. Translations
If you have a requirement to generate statements in multiple languages, allow enough time for translations. Your consultant can provide you with a Translations Workbook. Make sure that you have testers available to verify that items were translated correctly and that the statements make sense.
The following is an example of a Translation Workbook:
9. Logo
A statement logo, shown below, cannot be updated by a consultant – you will have to create a support ticket with SAP to update the logo. Ensure the logo you provide is the size that should appear on the statement. They do not size the logo; they create a URL with the logo that you send them. Separate tickets are needed for test and production.
10. Production Cutover
You have two options to move statements from your test environment to production:
- Recreate the statements in PROD. With this option you are reimporting the fields into the new statement templates, so validate that the correct fields are pulled in, the correct checks are recreated (for example, only display a field and/or section if the values are greater than 0), etc.
- Export the XML/XSL from test and import it into production. Compensation template IDs are different in test than in production, so update the IDs accordingly.
In either case, make sure that all changes to the worksheet in production that were not replicated in test are communicated to the consultant developing your statements. It may not seem significant to you, but these changes could affect your statements.
In Summary
- If possible, plan and develop your compensation statements the same time you design your templates to avoid manipulation of data in the statement XSL code.
- It is not recommended to change the code to accommodate items that you missed during development.
- Keep in mind that all compensation and variable pay worksheets must be in a completed status before statements can be generated.
Reference:
- SAP Help Portal (you will need an S-ID to access): https://help.sap.com/
About the Authors
