The SAP Enterprise Compensation Management (PA-EC) module allows companies to design a comprehensive, performance-based compensation program that supports their specific requirements. The module provides components for annual and variable pay administration, long-term incentives, budgeting, and job pricing.

Although the EC functions may support an enterprise-wide total compensation strategy, most companies tend to implement specific functions of EC at certain times and over several phases. I’ve found that most companies administer a scheduled (annual) merit increase review process and one or more variable pay plans (bonus plans) for employees.

I will focus on several key lessons learned that pertain to implementing annual merit plans, variable pay plans, budget reconciliation, and approval processing in the EC module. I’ll describe how to integrate promotions and lump sums into these processes. This information will allow you to evaluate how to best use the EC module in your business environment, what types of master and organizational data and process adjustments you must consider as you implement EC, and also how EC might facilitate some business process improvements within your company. I’ll also explain how to design a custom plan/budget review report and customize EC using Business Add-Ins (BAdIs). Refer to the sidebar, “Using BAdIs with EC,” for more details about BAdIs.

Integrate Pay for Performance Using EC

In today’s competitive pay environment, a pay for performance aspect to compensation is critical. An employee’s performance rating is a key factor in determining any salary increase or bonus decision that the employee’s manager makes. EC fully supports this approach. You can display an employee’s performance rating from master data on the EC planning screen (Figure 1). The delivered roles in the standard EC functions are: Manager (Planning), Compensation Specialist, HR Manager, and HR Administrator.

Figure 1

Planning view in MSS that displays an employee’s appraisal rating. Note that you can manage both hourly and salaried employees within the same plan design.

Many companies use a single tool, spreadsheet, or screen to give a raise and assign an employee performance rating at the same time. When determining pay adjustments in EC, managers consider the value of an appraisal rating, but the actual performance assessment and rating assignment process does not occur in EC. Managers must process and complete the performance rating before the EC module can use this rating to recommend default pay increases. The SAP Objective Setting and Appraisals (OSA) module (where you assign performance ratings) integrates with SAP EC and uses completed performance ratings to calculate recommended pay increases or bonuses in EC plans.

Your company should not expect to allow managers to adjust an employee’s performance rating during EC salary increase planning in a standard SAP system. Rather, the goal of the manager’s planning function in EC is to facilitate the manager’s task by providing system-recommended defaults for merit increases or bonuses based on predefined guidelines (including performance rating).

Guidelines are configured values for the compensation amount, percentage, or number that default for employees in a manager’s MSS planning screen during the EC planning process. Company-specific criteria for assigning award or increase amounts determine the guidelines. Employee management best practices dictate that you process employee performance ratings prior to initiating salary or bonus pay decisions, and the design of the EC module supports this practice.

However, you may use anticipated or projected performance ratings to budget for employee increases or bonuses. In the EC budgeting processes, your company can create a budget for your annual or bonus plan based on anticipated performance ratings or previous year ratings of employees. Companies frequently use this approach to determine a target pool for annual pay increases.

In some scenarios, you might adjust current business practices based on an implementation of EC. For example, a company has a pay for performance-based annual increase plan and uses the employee performance rating to calculate the maximum increase the employee may receive. If a manager fails to rate the employee, the manager may still enter a pay increase for the employee. This is a control risk in the process, since a manager can potentially enter an increase that is subjective and not based on published guidelines or objective, predefined system calculations.

If your current process allows managers to enter rating data and pay increases at the same time and manipulate either value according to a budget composite, SAP recommends that you adjust your business practice to separate these two processes. Making this change not only allows you to use the standard EC functions; it reduces the risk of allowing ratings based on factors other than true performance measures.

Planning Period

During the planning period, managers review and enter increase amounts, submit them for approval, and re-evaluate any rejected records. This period begins when a plan budget is complete and released and ends when all pay adjustments have an approved status and are ready to update employee pay records. At many companies, this period of time varies, but it may last four months or longer. When implementing EC, companies should consider reducing the length of this planning period.

EC planning and approval screens allow managers to review recommended increases, make updates, and submit, approve, and reject award amounts. This can reduce your planning period because it eliminates the need to constantly update and distribute spreadsheets.

I recommend that you keep the planning process as short as possible. Keep in mind that most managers perform their planning tasks either immediately or on the last day of the planning period regardless of the total time frame. A condensed time frame also creates less monitoring and support work for compensation administrators or specialists.

Another reason to shorten the planning period is that managers must work with a set amount of budgeted funds in their EC plan. As changes in the organization occur (such as new hires, transfers, retirees), EC’s budget does not update.

If you cannot avoid personnel changes during the planning period, EC provides a function in the Compensation Specialist role to move budgeted and spent money from one organizational unit to another. This re-allocation function is a standard system process that you can use anywhere in the organizational hierarchy.

Business Scenario

Reviewing existing business processes and trying to streamline them wherever possible is very valuable. One company I worked with initially configured an annual increase plan and based recommended increases on an employee’s performance rating and position. When the EC system proposed an increase based on these two criteria, managers had some discretion (within budget) to adjust employees’ increase amounts. However, as the compensation department and upper management continued to refine the annual increase process, they decided to completely remove the step of allowing managers to change the system-defaulted increase.

With this business process in place, a centralized group (such as the compensation department) administers the annual increases within standard EC batch processes without manager input. When the central group had processed the increases, managers could view the increases for their employees via the standard MSS EC planning screen. Managers did not have to perform any adjustments or submit any recommendations using EC. They viewed the final increases for their employees and notified them of the amounts they would receive.

This change to the existing business process greatly reduced the time managers spent administering the plan, compensation support staff time, and the total length required for administering annual pay increases in the company. Of course, completely eliminating manager discretion from a pay planning process would not work for every company or plan.

Budget Reconciliation

During the planning period described above, most users want to monitor how much the managers award and the progress of the plan’s budgeted amounts. The system provides this information within the managers’ planning and approval screens so that the individual managers can work within their organizational units’ budgets. In addition, most executive-level personnel or compensation specialists want a centralized tool or report to use throughout the planning process to monitor overall process progression and verify budget compliance.

Monitoring of Compensation Budgets (RHECM_BUDGET_RPT), a standard EC Web-based budget monitoring report, displays budgeted and spent amounts for compensation plans. This report provides an overview of the organizational unit’s budgeted/spent amounts and roll-up amounts, but does not contain employee-level detail (Figure 2).

Figure 2

Report RHECM_BUDGET_RPT, Monitoring of Compensation Budgets, a standard EC Web-based budget monitoring report

If your company requires detail that the budget monitoring report does not provide, I recommend using the custom report I’ll describe later in the article. You can use this report to monitor employee-level budget and award information throughout the plan period as well as to provide senior-level summary information for final approval of the award amounts.

Approval Processing

Most companies have similar baseline requirements for the approval process for annual or variable pay increases. An employee’s direct manager or supervisor adjusts or recommends a raise according to the plan guidelines, and then submits the adjustments to the next higher manager to review and approve. After this process, custom requirements vary, depending on what type of senior-level or department-level approvals are required within the company. Some compensation or financial departments review all awards and budgeted amounts, and some may require director-level review and approval, even up to the CFO and CEO level.

Most recently, the Sarbanes-Oxley legislation and its impact on pay increase review and approval processes has prompted new concerns and questions when implementing an application like EC. Many users I have worked with initially request or expect a workflow notification and approval process to function within EC to capture, display, or send direct managers’ adjustments via workflow up to a higher level within the SAP organizational hierarchy.

The standard EC functions provide screens for direct managers and the next higher manager to make pay adjustments and review, approve, or reject the amounts. See Figure 3 for an example of the higher second-level manager approval/rejection screen within MSS.

Figure 3

Approval view in MSS

This design follows a best practice guideline that allows the direct manager and one additional higher manager to access review and approval screens via a Web-based user interface. Managers at any level in the hierarchy can access the planning screen and review recommended amounts for lower-level managers. Approval/rejection processing only includes those records that a manager’s directly reporting manager submits. Otherwise, a manager above a second-level manager would be working with a prohibitively large number of employee records. Companies that require a high-level approval process for directors or executives do not want hundreds or even thousands of approval verifications and workflow notices sent to these managers, nor do they want these managers to enter every employee record and approve/reject them.

Design a Custom Plan/Budget Review Report

I recommend that you create a summary or review report for executive or administrative levels and allow these persons to access the report via the MSS front end for these types of higher-level approval and review processes. This type of report typically allows you to display spent budget amounts throughout the organizational hierarchy at any time during the planning period, by organizational unit and at the detailed employee level. This approach ensures that a company can provide data about adjustments and budgets to high-level managers at any time during the planning process, and therefore meet any compliance needs specific to that company. The report can also serve as the control mechanism for any executive or department that must review proposed or actual increase amounts for annual or variable pay.

SAP provides the standard budget monitoring report RHECM_BUDGET_RPT shown in Figure 2. However, it does not include employee-level detail, only organizational unit roll-up. If your company’s review and approval processes require employee-level detail to be available to managers above the second-level manager, the type of summary report described above is a simple way to meet this requirement.

Tips to Create Your Report

• Infotype 1520 on object BU stores the original budget amounts for organizational units.

• Infotype 0759 in field CPAMT stores the spent values for an individual employee.

• Locate the total spent amount per budget unit by determining the value of ADATANR in table HRP1001. Execute transaction SE16, table HRP1001, and enter a search with relationship A/B300 (the relationship between the organizational unit and the budget unit). Copy the value for ADATANR.

• Execute transaction SE16, table HRPADPM. Enter the ADATANR value from the step above in this table field with the same label. Execute the search and the system returns the value of the spent amount for the budget unit.

• Reference the code for the standard budget monitoring report (RHECM_BUDGET_RPT) to find sample code in the function modules for reading budgets for organizational units. This report provides budget reconciliation data. You can incorporate most of the function modules in your own report and perform additional coding to display employee-level detail.

• Be sure to include the plan status as a selection and display parameter in the report. This allows more flexibility for central monitoring purposes throughout the plan period.

Data Changes to Support EC

During the pre-planning and requirements-gathering phases of a project to implement EC, it is common for companies to determine that they require a change to employee or organizational data. This does not imply that there is anything wrong with current master data or system design; it means that they must link additional details or groupings to existing data to fulfill the EC design requirements. For example, it is common for companies to base a variable pay or bonus plan award on a target award percentage, and for the employee’s job family (or similar job grouping) to decide this percentage.

However, the existing SAP master data may not contain a job grouping element with the associated jobs and bonus target percentage. In this example, a company could create a new object type for job family, create the required objects representing each family, and then create a relationship between each object and the linked jobs. You can perform these steps via standard SAP configuration and then create a new Personnel Development (PD) infotype to use for the job families to hold a bonus target percentage. You can set up EC to identify and include this target percentage (associated to employees via their link to position, job, and job family) as a factor in the guideline for the bonus.

For similar requirements, many companies choose instead to create a custom table that contains a job family or grouping as a primary key with the existing system job objects in the table as elements linked to the appropriate job family. The table entries can contain start and end dates, so you can update them on an annual basis or as needed. This approach achieves the same result for EC as the option above, but with a custom table instead of a new infotype.

Table 1 shows an example of a custom table that you could create to identify target percentage amounts by job groupings. Note that MOLGA is a primary table key and you must use it if you are implementing EC globally. The second entry in the table is the plan ID, which links the table entry to a specific configured plan in EC (make this a table check field against V_T71ADM02).

The third entry is the SAP job object number and the fourth is the company-assigned grouping number (which you can reference in EC configuration for the bonus plan guidelines). Each entry also has a validity period definition.

Some users incorporate a target percentage for variable pay into the naming conventions for their salary structures (pay type, area, grade, and level). If this type of scheme is already in place in your configuration, EC can use it for budgeting and guidelines calculations. However, I recommend one of the previously described design options over the salary structure approach because it’s easier to maintain and update the targets when you link them to a job, job grouping, or position instead of directly to the employee (as in infotype 0008 in the salary structure).

As early as possible in the planning phase, your company should identify specific plan requirements so that you can create, add, and test any new data elements to the system when configuring the plan. When you have clearly documented your requirements and plan calculations, you can easily determine whether you have the necessary data in your existing SAP system to support EC calculations. If you do not have the required data, you can design the appropriate data structures and coordinate their implementation within your EC project.

Promotions and Other Actions

Many companies plan for and perform promotions at the same time as annual pay adjustments. Some companies even consider promotional increases as part of the annual pay increase budget. Other companies include promotional increase amounts in a budget or pool for salary increases, while some budget separately for promotions.

The EC module can support budgeting and planning of promotional increases within the same budget as a single plan or as separate entities. However, EC does not integrate with an infotype 0000 (actions) record. Many companies implement a manual process as a workaround — for example, a spreadsheet that managers complete. Then, HR runs it through actions as a separate process. 

Also, some companies opt to have the promotion as a separate plan in EC and process this at the same time as yearly pay increases. A promotional increase plan and an annual

merit plan can link to the same budget in EC. Some companies have developed Personnel Change Requests (PCRs) for promotions and off-cycle base pay adjustments that the system processes before the final annual pay adjustment amounts are active.

Other companies use a PCR hyperlink solution on the worksheet. This is a custom link in the EC planning page that a manager clicks on to access a new MSS page for the standard PCR screen. This approach allows the manager to initiate a PCR for a promotion and then return to the EC page to complete the pay planning process.

However, SAP recommends that companies process promotions as basic actions. This means that you should make the pay adjustments to infotype 0008 as part of the action processing and manage the promotions budget (if applicable) outside of EC. If you decide to process promotion increases in EC, you need to define a process outside of the EC module to capture the action information in SAP master data (assuming you have promotion defined as an action in your system).

Lump Sum Payments with Annual Increases

Many companies want to give employees, under certain conditions, a lump sum amount instead of an increase to their annual salary or base pay. This scenario results when an employee is near or has reached the maximum of the pay range for his grade. If employees exceed the maximum of their grade before the system applies the annual increase to their salary, consider awarding the entire annual amount of the increase as a lump sum. If employees reach the maximum of their pay grade after paying the annual increase, then they receive part of the payout as an increase to the annual salary, up to the maximum of their grade. They receive the remainder as a lump sum amount.

Implement lump sums payment scenarios in EC using BAdI HRECM00_ACTIVATION. Remember that a manager cannot pay a lump sum amount in the planning and review process in the planning MSS screen of EC. Companies with a requirement to pay lump sums must predefine rules in the BAdI that specify the conditions under which to pay and how to calculate a lump sum.

For example, when employees’ raises exceed the maximum for a grade, a BAdI can check the grade maximum and the projected new salary for the employee and pay any amount over the maximum on the one-time payment infotype (0015, or 0267 for off-cycle payments on separate checks).

Employees’ grade limits might be a specific percent in the range or a compa-ratio value. To calculate this ratio, divide the salary by the midpoint of the applicable salary range. If this is the case, you can manage these conditions with the same BAdI.

If your company requires payment of lump sum amounts after reaching a pay grade threshold, SAP recommends that you clearly define the lump sum payout conditions and apply these uniformly throughout your organization. With these predefined conditions, an annual increase plan can incorporate your requirements and the system can automatically calculate and pay lump sums when appropriate using a BAdI.

I received a question from one company that wanted to pay out this type of lump sum throughout the pay calendar year for an employee. Although it is possible to include this logic in the same BAdI, it can involve a fairly complex design and coding effort, so I do not recommend this approach. If you must pay the lump sum incrementally, try to handle these instances as exceptions using manual processes.