Payroll has to happen correctly and on time, all the time. Getting the implementation done right is essential, and difficult. Over the past 10 years, I’ve been associated with more than a dozen SAP HR/Payroll implementations, varying in size, scope, and complexity. That experience has shown me there is a common list of items that tend either to go wrong or be left out. This list represents a good portion of what actually happens on real projects. Even if you have already implemented SAP Payroll, this article might give you some good tips for resolving current issues. So what goes wrong, what gets left out, and what is done incorrectly? Most im-portantly — Why does this happen and how can you prevent it? Here are seven ways your implementation can go awry.

1. Incomplete Pay Stubs

The pay stub is payroll’s primary communication vehicle with employees. A good pay stub is easy to understand and explains how the paycheck was calculated. A bad pay stub is confusing and incomplete — and it leads to lots of questions to the payroll department from employees. For example, a retrocalculation (a recalculation of a previous pay period) can be confusing to employees. The default pay stub delivered in R/3 is used as a starting point for custom pay stubs in most projects. It shows the total retrocalculation amount as one lump sum called “retro difference.” Suppose a simple data entry mistake was made in a previous period, entering 1.5 hours of overtime paid at 1.5 when it should have been 6 hours of overtime paid at 1.5. The employee’s pay stub then shows a difference of $185.63 (Figure 1). He will call payroll to find out what that sum was for. You can configure the pay stub to show the retro difference per wage type instead of as one lump sum. In that case, the employee sees the difference in overtime paid as a separate line denoted with a “P” or an “R” in the first column, telling him this was a previous period or retroactive change. (See Figure 2.) It then shows all the current period wage types. The employee knows exactly what was changed and paid, and doesn’t call the payroll department.   To enable the display of retroactive differences per wage type, the pay stub has to be printed with the Layout of retroactive runs set to S and Print retroactive runs to X. You have to configure the HR form (an executable report with its own selection screen) with a special rule to recognize wage types from retroactive periods. The rule also displays them with different column types to separate them from current-period wage types. See Figure 3, which shows the parameters for the remuneration statements program (RPCEDTx0).   On the payroll form fields used in Pre-DME (Data Medium Exchange), this translates to ZUAB/A /X/S/1/B/ /. The rules in the HR form have to recognize current periods vs. retroactive periods, and display them via different line layouts. A sample configuration, using wage type /101 as an example, could look like the coding shown in Figure 4.

Tab Wtype Ltype Ctype Rule ... Comment RT  /101  98    X     98       Retro value always on single line RT  /101  99    1     99       Actual value Rules: Rule# "Comment 98 1 XRT FPEND LT PN-BEGDA "skips actual 99 1 XRT FPEND GE PN-BEGDA "skips retros Line layouts: 98 X R LGTXT_____________ BETRG__________ 99 1   LGTXT_____________ BETRG__________
Figure 4	Sample configuration using wage type /101

2. Off-Cycle Payroll Cut from Project

In addition to regular, scheduled paychecks, R/3 has the capability to produce off-cycle checks, including bonus checks, checks that correct errors on previous checks, reversals, and other types of adjustments. R/3 provides the Off-Cycle Workbench and Off-Cycle Process Manager (also called HR Process Workbench, transaction code PUST) to automate the processing of off-cycle payrolls. These tools take care of back-end check printing, accounting, and associated processes for each off-cycle check created. The off-cycle configuration is sometimes cut from an implementation. Companies may eliminate it from the scope to save time and effort, or because they assume that since they don’t currently have many off-cycle transactions, they don’t really need it in R/3. However, those companies are missing out on a significant part of R/3’s payroll capability. It’s my opinion that a fully functional implementation of SAP’s Payroll module depends on a complete implementation of the Off-Cycle Workbench. It is technically possible to refrain from using it, but the resulting workarounds cause more effort than the initial configuration. The Off-Cycle Workbench enables and automates check reversals, correction checks, bonus checks, and payroll adjustments. The Off-Cycle Process Manager automates all the back-end processes (accounting, check printing, direct deposit). By implementing special ABAP coding (workflow objects called “containers”), your technical team can integrate custom interfaces, such as those to 401(k) providers and other external systems, into the Off-Cycle Process Manager. For more detail on programming with containers, search the PY-XX-TL section of OSS.

3. Tax Reporter Overlooked

Project teams often become so focused on getting the payroll calculation correct that other important aspects of payroll are ignored. Quarterly and annual tax reporting is one of these. R/3’s Tax Reporter functionality (PU19) provides a set of regulatory tax filings forms for federal, state, and some local tax authorities. While there isn’t much configuration for Tax Reporter, companies too often go live without configuring, testing, or even knowing about it. When their first tax reporting period comes along, they scramble to get it done. Make sure that quarterly and annual tax filing processes are part of your business scenarios. Configure and test them along with all the other scenarios. For example, after running a series of payrolls for employees in integration testing, run quarter-end tax reports to make sure they are accurate, and reconcile them back to the payroll results and FI/CO postings.

4. Schema and Rule Configuration Errors

Configured correctly, payroll schemas and rules for customized payroll processing are very useful. When they are done incorrectly, the results can be disastrous. The following three configuration mistakes are common. Hard-coding wage types in rules leads to difficulty in making date-effective changes to calculation logic. This is termed “explicit” use of wage types. Wage types are used implicitly when you reference them via special wage type attributes such as processing (operation VWTCL), cumulation (CUMWT), or evaluation (EVLCL) classes. These attributes of wage types are date-effective via view v_512w_o (use transaction SM30 to access that view). Customers can create their own processing, cumulation, and evaluation classes, in addition to using the SAP-standard classes. Rules and schemas are not naturally date-effective; therefore, whatever changes you make to them apply to all time periods. Since payroll calculation logic changes over time, an implicit reference to wage types gives customers more ability to adapt to change. The implicit reference method typically is not practiced well when systems are initially configured because people make assumptions that the logic will not change in the future. Hard-coding other values (amounts, number, rates, constants) in rules leads to problems. For example, suppose one wage type is multiplied by a rate to get a new one. You could multiply the wage type by .45 in a rule, but that rate could change in the future. Figure 5 shows individual wage types (0001, 0003, and 0005) multiplied by 0.45 and then summed into wage type 9901. This rule works, but if either the wage types or the rate change, you don’t have a convenient way to make those changes date-effective.   Here’s a better method: Go to table t511k. Create a constant with a value of .45 and use the constant in the rule (AMT=K<constant>). Since t511k constants are date-effective, you can control the rate by effective dates if it ever does change. The next rule does the same thing, but by referencing wage types via a custom-processing class 99 and using a constant to hold the rate (see Figure 6).   In this rule, you multiply any wage type that has a processing class 99 equal to 1 by whatever is in constant Y0001. If processing class 99 for the current wage type is equal to a 1, you first pass the current wage type on to the next step in payroll (ADDWT *). Then, set the AMT field of the current wage type to whatever is in constant Y0001 (AMT=KY0001). Multiply the NUM field by the AMT field and store the result in the AMT field (MULTI NAA). Then sum the results into wage type 9901 (ADDWT 9901). If processing class 99 for the current wage type is not equal to 1, simply pass the wage type on to the next step (ADDWT *). Since both wage types and constants are date-effective, you have a much more flexible rule. Wage-type splits relate a wage type to additional information needed for special processing. You should eliminate splits only when it’s absolutely necessary. For example, a split may link the wage type to a cost center, a tax agency, or a company code. They are widely misunderstood and often are eliminated in the payroll calculation (payroll operation ELIMI or processing class 20, for example). Without a thorough understanding of SAP Payroll configuration and the role splits play in the payroll calculation, it’s tempting to eliminate them because splits can make it harder to customize the payroll calculation. However, the elimination of these splits can lead to payroll errors when someone changes company codes or cost centers in the middle of a pay period. In that case, when payroll is run it creates wage-type splits to allocate amounts based on the various company codes or cost centers. If those splits are eliminated in the payroll calculation, then you lose track of how much to allocate.

5. Outdated Payroll Reports

Another area of R/3 Payroll that is often misunderstood and poorly applied is reporting. R/3 Payroll reporting for the United States has changed over the years, and it is different from other countries. With more than 4,000 tax authorities, check reversals and voids, various payroll frequencies, and manual payroll adjustments, U.S. payroll reporting is challenging. Consultants and implementers who do not keep up with these changes and differences often leave significant gaps in reporting for their clients. The best way to keep up with these changes is to stay familiar with OSS and release notes. The four general areas of R/3 Payroll reporting – regulatory, reconciliation, analytical, and period-based – each have corresponding standard reports. Before developing custom reports, customers must be aware of what the standard reports can, and cannot, do.

• Regulatory – These reports provide data to tax authorities and other regulatory agencies. Tax Reporter (PU19) is used for reporting taxable wages and taxes to tax authorities in the U.S. R/3 provides RPCPL7U0 for sending U.S. garnishments data back to their originators. Other countries have corresponding standard reports for their particular regulatory agencies.
• Reconciliation – R/3’s Payroll Reconciliation Report (RPCPRRU0) is specific to the United States and is designed to reconcile payroll to Tax Reporter, and payroll to FI/CO. It has special logic not contained in other reports that aids customers in the reconciliation process. Even if you do not use the FI/CO system, this report can be used to reconcile accounting since it reports payroll results in the same manner they would be accounted for in any accounting system. SAP has recently released a Cost Center Manager’s report that has many of the same functions to reconcile payroll to FI/CO.
• Analytical – For analytical reporting, most customers will find that interfacing payroll to SAP’s Business Information Warehouse (BW) provides the best analytical reporting functionality. R/3 also has functionality to copy selected wage-types from payroll results back into payroll infotypes, which then enables you to use SAP Query to create custom reports of your payroll data. If you do not use BW or the payroll infotypes, some third-party tools provide similar functionality, but with significant processing overhead. R/3 stores the payroll results data in cluster tables, which is good for sequential processing, but not for analytical reporting. Each of these reporting schemes requires copying the payroll results from their cluster tables into a reporting database (i.e., BW, infotypes, or another tool).
• Period-based – After a payroll run, you have to report various pieces of data both internally and externally. Certain deductions (parking, cafeteria, loans) may be reported back to their originators, for example. The wage type statement (RPCLGA09) and wage type distribution (RPCLGV09) are good reports for this. R/3 also has a Wage Type Reporter (H99CWTR0) that uses the ABAP list viewer for more flexible output definition. You can also use the payroll journal (RPCLJNU0) for reporting period-based activities. Its output is defined with HR forms (a tool for formatting payroll results for display to users) which you can configure via the HR Form Editor (PE51). These reports are not appropriate for regulatory or reconciliation purposes in the United States since they do not take into account how reversals, retrocalculations, and taxable wage offsets are handled. Outside the United States, many companies find the Wage Type Reporter suitable for reconciliations.

Payroll reports are available via the payroll menu at Subsequent Activities > Per payroll period >  Lists/statistics and Subsequent Activities > Period Independent > Payroll Supplement. Access Help text for each report through the Help > Application Help menu path at the selection screen of each report.

6. Testing Is Shortchanged

Payroll testing is often compromised so that projects can go live on a certain date. While cutover decisions always have to balance a number of factors, going live with a payroll system that does not work correctly results in serious consequences. Employees are not paid correctly, tax payments may be incorrect, payroll expenses may not be booked correctly in FI/CO, or paychecks might be delivered late. These two processes in particular need to be tested: When going live in the middle of a year, you have to load the year-to-date payroll data for each employee at conversion. If this conversion is not accurate, payroll calculations and reporting will be incorrect. These errors often show up when customers test the year-end or quarter-end tax reporting. They find items that were not converted — such as imputed income on group term life insurance, employer unemployment wages, and various statistical wage types used for unemployment reporting. Making these corrections after go-live can be complex; resolving them at go-live is much easier. Setting up custom interfaces from SAP payroll to external systems can be a difficult task. Testing the interfaces is likewise difficult. The most common mistakes in payroll interfaces are that they do not correctly handle retro-calculations and off-cycle payrolls. Neither of these is insurmountable. You can program the interfaces to handle them. All too often interfaces are not tested well, and then after cutover, it’s discovered that they don’t work correctly.

7. Deduction-Processing Conflicts

R/3 Payroll offers many options for processing deductions. Some can conflict with each other, giving users strange results: “Why was this deducted when it does not show up in infotype 14 or 15,” or “Why did payroll deduct more than normal this time?” Sometimes configuration is not documented or correct – again confusing users. One example is the relationship between retrocalculations (a recalculation of a previous payroll period) and arrears processing. Arrears are amounts of a deduction that could not be taken from the paycheck because of insufficient funds, perhaps because of an overpayment in a previous period or an unpaid absence in the current period. R/3 has customizing for handling arrears in the current-period calculation as well as for retrocalculations — which is what leads to some of the confusion. This is controlled via the wage type settings in view v_t51p6. The current period settings offer a lot of options for arrears (Figure 7). If there is not enough money in the paycheck to take a deduction, you can (among less common options) just forget about it (Arrears option 5), take as much as of the amount as possible and forget about the remainder (Arrears option 2), or carry that remainder to the next pay period and try to take it from that paycheck (Arrears option 3).

Tab Wtype Ltype Ctype Rule ... Comment RT  /101  98    X     98       Retro value always on single line RT  /101  99    1     99       Actual value Rules: Rule# "Comment 98 1 XRT FPEND LT PN-BEGDA "skips actual 99 1 XRT FPEND GE PN-BEGDA "skips retros Line layouts: 98 X R LGTXT_____________ BETRG__________ 99 1   LGTXT_____________ BETRG__________
Figure 7	Options for arrears (view v_t51p6)

You have different options when a deduction changes retroactively (Figure 8). R/3 will recalculate the deduction, and if a difference is found, you can ignore it or roll it into the next period and process it there. Let’s say you retroactively (one pay period in the past) increased someone’s credit union deduction from $100 to $120. When that period is recalculated, $20 more must be deducted. Since that period has already been paid, you can’t process that $20. You could roll that $20 into the current period and take it there, for a total of $140 ($120 current plus $20 from last period). Or you could configure the system to ignore that $20 difference, and take $120 in the current period. Depending on what the employee is expecting or what the payroll department really intends, this can lead to questions, such as why an extra $20 was taken. Or maybe the system is configured to ignore the difference, but payroll is expecting the deduction to be automatically corrected when it changes it retroactively. Other scenarios include ignoring arrears in the current period but rolling them forward in retro periods, or making changes to arrears settings but not making them date-effective.

Using Project Management to Avoid Problems

Good project management is one of the best ways to make sure your R/3 Payroll implementation avoids these seven pitfalls. Too many times project teams compromise testing, knowledge transfer and training, and documentation to meet an implementation date. Then, the quality of the implementation suffers, and the staff does not have adequate knowledge to maintain the system. Here are two tips for your project:

• Allot enough time for payroll configuration. Many project teams underestimate the time and effort required for payroll configuration, as well as the dependencies payroll configuration has on the configuration of time evaluation, personnel actions, benefits, and other modules, such as FI/CO. Until a good portion of these items is configured, the payroll calculation can’t be configured, let alone tested. Since the Payroll module is a major part of the system configuration, and it cannot start until other parts of HR are configured, it’s easy to see how the latter part of a project can be overwhelmed.
• If your project includes external consultants, use them wisely. To do good work, consultants need support from the customer. All too often, when pressured by time requirements on the one hand and a lack of business requirements on the other, consultants are tempted just to complete the technical work without fully understanding the business requirements. That can lead to a host of problems later in the project and in the production environment.

Many details have to come together to make a successful SAP Payroll implementation. A number of things can go wrong, but with good project management and a thorough understanding of R/3’s Payroll functionality, you can make sure you have an accurate and complete implementation.