When payroll goes into operation, the challenge of troubleshooting issues increases exponentially compared to the implementation or testing phases of the project. The cause of these problems can range from a faulty business process to a lack of knowledge of the SAP system’s payroll functionality. In some cases, both HR and payroll end users tend to create more problems due to lack of knowledge. These users are doing transaction entries for payroll or are involved in running payroll. Therefore, categorization of the issues and following definite paths in each category help resolve any problems. The three principles of good payroll systems — accuracy, timeliness, and compliance — are the foundation for finding solutions to problems. Before I get to the issues and troubleshooting discussion, let’s see if there’s such a thing as preventive maintenance for payroll. Typically, payroll users are in a rush to release the payroll control record to start the payroll runs. Once they release the control record, they also get into a problem of exiting the payroll (completing and confirming). Can you, for example, proactively look for issues and problems before releasing payroll control records or prior to exiting the control record? Yes, you can look for pre-payroll checks and run reports to ensure that the quality of the data going into payroll is maintained at acceptable levels. Such pre-payroll checks also help reduce run-time errors (e.g., in infotype 0009 [missing bank details] for new hires). Such pre-payroll audits assist in reducing errors during the payroll run. (If you are not familiar with the SAP system’s payroll control record, you can read about it on SAP Help.) These checks depend on the following factors:

• The time between two payroll cycles: Typically, weekly payroll cycles allow only a limited time for running payroll simulations. The actual payroll cycle of release – release for correction – exit could also be shorter, creating challenges for preventive-issue searching.
• The availability of payroll clusters: Some of the reports (e.g., wage type reports that compare previous pay period gross numbers and current pay period gross numbers) require clusters and cannot be run in simulation mode. Therefore, the payroll cycle needs to be long enough so that payroll users can run such reports while still in the control record. Also, if payroll users who manage payroll run-time transactions and reports find problems, they should approach HR users to correct any data. In many organizations the segregation of duties is such that HR handles the data entry (either centrally or distributed) while payroll users are involved with the running of payroll and managing the outcome and outputs from payroll. For example, HR carries out changes of salary and manages basic pay (infotype 0008) while payroll looks at the impact of retroactivity if HR has retroactively changed such data.
• The service delivery model: If payroll operations are outsourced, this is a different matter altogether. For example, the outsourced vendor then needs to handle the preventive maintenance (described in more detail below) and preventive maintenance needs to be part of the service level agreement (SLA) if necessary.
• The availability of tools: Organizations handle preventive maintenance in a few different ways. Some use standard SAP reports and queries while some develop custom reports. Some organizations also use third-party tools. Payroll implementations build their own queries and reports for such work. In some cases, SAP ERP HCM and payroll users (implementations) also use third-party tools. These tools come with pre-built rules that are described below.

A simple question that most payroll managers have is, “Are we paying everyone that we are supposed to pay and making sure that we are not paying someone that we are not supposed to pay?” This may sound obvious, but this is the basic underlying issue in any discussion about payroll troubleshooting and preventive maintenance.

Assessment of Payroll Infotypes

Payroll infotypes such as 0007, 0008, 0014, 0015, 0027, 0221, and 2010 are normally maintained ahead of payroll cycles. In most organizations, these changes are also done by HR users (as discussed previously). In some cases these HR users could be in a centralized shared-service environment or, alternatively, in a distributed environment. The typical indicative data that you should look for are:

• Retroactive data changes
• Amounts in infotype 0008 (basic pay) that were changed to amounts lesser than the current amounts
• Future-dated infotype changes
• Specific wage types for the organization
• Locked infotypes
• Misalignment between infotypes 0007 (work schedules) and 0008 (basic pay) — for example, work hours and capacity utilization
• Missing recurring payments and deductions in infotype 0014 (for specific wage types)

Assessment of Tax Infotypes

In the US, tax infotypes can use rules such as:

• Infotypes 0207 (residence tax) and 0208 (work tax) with different tax areas
• Missing unemployment infotype 0209 (specific states) from infotype 0006 (address)
• Missing W-4 infotype 0210
• Specific employee types — such as expatriates and students — and existence of infotype 0235 (tax exemptions)

Assessment of Benefits Infotypes

Examples of preventive rules for benefits infotypes are:

• Employees with a missing health plan (infotype 0167)
• Existence of infotype 0021 (dependents and coverage grouping) in infotype 0167— for example, single coverage in health plan and valid dependents in infotype 0021

Other common indicative data to avoid payroll issues are:

• Specific cost centers in infotype 0001 — for example, you may be looking for inactive cost centers in a split HR- and financial-system scenario
• Misalignment between payroll area and employee group or subgroup, especially in an implementation in which features were not properly set up
• Missing or split infotype 0009 (bank details)
• Employee with a valid infotype 0027 (cost distribution), with valid cost centers or other financial data, that assist during financial reconciliation

Most payroll implementations run indicative reports comparing previous payroll periods using standard SAP system wage type reporters. For example, reports that:

• Compare total gross between the previous period and the current period. You need payroll clusters to run these reports.
• Compare other wage types such as total garnishments or total taxes to get order-of-magnitude or reasonability checks

Troubleshooting Steps

To troubleshoot payroll issues, you should rely on some commonly used tools and methods that I have listed below. In addition, there are some unique solutions that I discuss later in this article:

• Ad hoc query using infotypes to check specific infotype data within a chosen date range. For example, changes to infotype 0009 and infotype 0008 in which amounts are greater than a user-specified amount.
• Audit log reports (by turning on the SAP system’s audit functionality for infotype changes). The SAP system standard report RPUAUD00 provides the change details. The infotypes included in the report have to be chosen by the user through configuration for tracking the changes.
• Wage type reporter (especially to compare amount totals for a wage type across two consecutive pay periods)
• Cost center report (report RPCPCC00)
• Standard SAP reports (such as the employee listing by status report)
• New hire report (used to check the number of new hires during a pay period)
• Remuneration statement with retroactive parameters. The SAP system standard remuneration statement output looks different depending on the parameters you choose in the print program RPCEDTU0 (transaction code PC00_M10_CEDT). Some of these parameters are print retroactive run, sort retroactive run, and layout of retroactive runs.

Reconciliation of Time and Payroll

Typically in SAP ERP HCM and payroll implementations, there are time clocking and time evaluations carried out in external time systems, in the SAP system, or in both. Time systems and time evaluations feed data to the SAP payroll system. In many cases when external interfaces (e.g., Kronos or Kaba) feed the data to SAP system infotypes such as infotype 2010 (employee remuneration), it is a challenge to reconcile the handshakes. For example, the external time-clocking system loads the date, hours worked, cost center, and pay rate in infotype 2010 (employee remuneration). The handshake in this example could be an interface loading the data in this infotype. The interface could potentially round numbers or adjust dates. The handshake basically refers to data elements that transfer and change hands between the external system and SAP ERP HCM. If the external time-clocking systems are handling seasonal workforces, then the employee population numbers could change from one pay period to another. This can result in:

• Errors in the interface from the external time-clocking system
• Mismatching of the status between the SAP system and the external time-clocking system (due to late termination actions or errors in interface from the SAP system to the external time system, for example)
• Challenges to reconciling active and inactive employees between the time clocking and SAP ERP HCM systems. For example, SAP ERP HCM is a system of records — this is the system in which employee hiring and termination records are kept. SAP ERP HCM sends an interface to the external system with these employee data changes. If the termination data is sent late to the external systems then an employee could potentially be inactive or terminated in the internal SAP ERP HCM system while remaining active in the external system since the interface update is late.
• Missing payments due to terminated employees or employees who have resigned or retired, which results in arrears
• Differences in retroactive procedures in the time-clocking system and the SAP payroll system

Many users have told me that payroll troubleshooting is an art rather than a science. I do not believe that statement. If you can develop methods to troubleshoot these issues, you find that you can establish a science. As discussed in this section, the standard paths that you can start exploring to make payroll troubleshooting more concrete are:

• Data and retroactivity (using audit or any other reports)
• Interface file issues and data uploads
• New users and business processes
• Output interpretation such as totals or printing retroactive data in reports

The following section uses examples of issues and the troubleshooting steps taken to avoid or correct these common problems. This brings me to the issues that occur during or after the payroll exit — the issues that need deeper troubleshooting. I show different examples for this discussion and follow an issue or solution pattern.

Excessive Overpayments During Payroll Run

Issue: Most of us know that overpayments are caused by late terminations or correcting some overpaid amounts in past periods. In both new and old overpayments utilities in the SAP system, you are able to see overpayments before exiting the payroll and during the correction cycle itself. Are there any industry best practices or key indicators about the number of overpayments? Not really — it’s up to each payroll manager to know if they have excessive overpayments during a payroll run. The golden rule is the fewer the number of overpayments, the better, especially since overpayments require effort to clear them up with the associated financial postings. Troubleshooting steps: The starting point for resolving overpayments is:

• Run a report to find out which termination or employee status change actions (to inactive or terminated) were carried out with retroactive dates in current pay periods. This report should tell you the number of employees and who carried out the transactions. Such reports can be developed using ad hoc query in SAP ERP HCM or by developing a custom report. The report needs to read infotype 0000 (actions) for an employee and then compare the dates with current payroll control record dates. Alternatively, a standard wage type reporter or payroll journal can also be used to check retroactive payroll results.
• Run a report to find out if any payments or rates for payments were reduced retroactively. For example, the hourly rate was reduced downward and, therefore, associated basic earnings and overtime need to be taken back as a result of overpayment. Such reports can be run using standard SAP audit logs for changes to infotype 0008 (basic pay) or another infotype (e.g., 0014 [specific wage types] or 2010 [employee remuneration]) where rates are maintained. Some of these late data entry issues could be linked to the business processes. For example:
• The termination of business process may have too much manual intervention, causing delays in the action
• The time-clocking system processes are such that they pay people based on planned hours and then make adjustments based on actual hours in the following pay period. In many cases, when employees work less than their planned hours, the SAP payroll system creates an overpayment since the time-clocking system sends retroactive reduced hours for previous pay periods.
• An employee is absent due to illness, but continues to be paid for sick leave. The employee then files for disability and is expected to be paid directly by the disability service provider. The HR user (who maintains transactions and data for employees) then goes into the employee record and retroactively makes data changes, which creates overpayments for this employee.
  • Check to see if your implementation is using old claims or new overpayments (post-enhancement package 4) functionality. Depending on the case, you should follow old claims schema or new overpayments utility procedures to identify and clear the claims, respectively. The new overpayments functionality was released by SAP in enhancement package 4 in late 2008. If your implementation is not on this level of enhancement package then you do not see this functionality. The easiest way to check is to follow menu path Payroll > USA > US Overpayment Recovery.

CATS Data Entry and Manual Errors

Issue: Employees who are entering data using the Cross-Application Time Sheet (CATS) encounter payroll errors and there are also too many retroactive changes. Troubleshooting steps: CATS time entry does not always have an approval process built into it. Therefore, the manager can retroactively challenge the employee’s time entered and, in some cases, cause the error. Also, a CATS screen does not have very sophisticated validations and edits. As a result, employees may sometimes choose the wrong time wage type or the wrong attendance type. This scenario has two solutions: a business process (manager approval) and CATS configuration and profile creation-based solution. Let us briefly discuss these two scenarios:

• Adopting manager approval for time: The manager can review the changes made by employees including the changes to the past time sheets. This review and approval step helps reject the time sheets at the source and does not allow the data to go up to the payroll.
• Customizing CATS: The SAP system provides user exits to develop additional edit checks and functionality in CATS. There are around a dozen such user exits (CATS0001 through CATS0012) that you can review to find out if they are useful for incorporating additional edits or validations.

New Hires Are Not Being Paid on Time

Issue: New hires are missing pay cycles and are not being paid on time. As a result, new hires are approaching HR for off-cycle paychecks — payroll is not happy about off-cycle runs. Troubleshooting steps: This problem can exist for both salaried and hourly employees. For salaried employees, the new-hire process seems to be disjointed with data entry required separately by HR, benefits administration, and payroll administration. As a result, the new-hire process is taking much longer to complete than it should. There are a few options to resolve this issue.

• For salaried employees, the issue seems to be the design of the business process. It is possible that the issue is that HR, benefits, and payroll have separate data entry responsibilities because of segregation of duties, or it may be because HR is responsible for employee hires, but the benefit enrollment or payroll deduction details are not available to HR. Some options to correct this issue are:
• For hourly employees, the problem compounds because there’s an outbound interface from the SAP system to the external time-clocking system that is missed as a result of late processing. Therefore, hourly employees are not able to log their time. Some options to correct this are:

• Allow more time for the new hire cycle and design the business process such that new hires are paid in the following regular cycle
• Build the system and customizations such that, if the benefits or payroll data is not received within a stipulated time, then the system makes default choices. For example, if benefits choices are not completed and entered in the system by a certain date, the system chooses default benefit plans.

• Running the SAP system to external time-clocking system interface more often. For example, this interface currently runs only once a day, but the time system gets the data for new hires much faster if it’s scheduled to run multiple times during the day.
• Paying hourly employees based on planned worked hours from infotype 0007 and adjusting the hours automatically in the following pay period. This avoids off-cycle payroll runs and reduces the number of complaints from employees about delayed paychecks or paychecks with missed earnings.

Certain Classes of Employee Are Being Paid Inaccurately

Issue: Hourly or shift employees who are on time clocks are not being paid correctly. The shift-rate calculations are incorrect and, in some cases, the Fair Labor Standard Act (FLSA) rate averaging is incorrect as well. Troubleshooting steps: In this scenario in which employee payment rates could be manipulated in both the external time-clocking system and SAP ERP HCM, time and payroll integration can make troubleshooting slightly harder. For example, SAP ERP HCM maintains the base hourly rate for an employee. However, the time-clocking system has an override rate if the employee happens to do a different job than the base job maintained in SAP ERP HCM. In this case, if the employee is not paid correctly, the troubleshooting steps are to:

• Confirm that the hours and time wage types are transferring correctly from the time system to the SAP payroll system
• Double-check the base rate for accuracy. For hourly employees the base rate may change and not necessarily equal the rate in infotype 0008. If an hourly employee carries out one or more jobs at different rates, then the time system sends the different rates to the SAP payroll system.
• Double-check to see if the shift rates or overtime rates are calculated based on the higher rate if the employee has worked in more than one job, and to ensure that the FLSA-rate calculations are compliant
• In certain implementations, teams also use custom (z) tables to maintain shift rates and build logic for payroll schema to read these tables and to derive the correct shift rates. In those situations, analyze the logic to ensure that the shift rates are accessed correctly.

Late BSI Tax Factory Updates

Issue: The implementation was late in applying a certain BSI tax update bulletin (TUB). This update had a tax rate change for one of the state taxes. You need to ensure that this tax is deducted at a higher rate than it was previously since the state has increased the rate. Troubleshooting steps: Use the forced retroactive accounting functionality in the SAP payroll system driver to force the retroactive calculations. When you force retroactive accounting for all employees in a payroll area, the SAP payroll system uses the new tax rates that are applicable for the retroactive calculations and deducts them in the current period.

Off-Cycle Payroll and General Ledger Posting Errors

Issue: Many off-cycle payrolls were completed during the week. The general ledger posting interface runs once a week and picks up all the posting documents within that week. Then it was noticed that one of the off-cycle runs did not reconcile as the user overlooked the posting run results for that off-cycle run. For example, the off-cycle run has a garnishment payment for a vendor. The general ledger posting missed this entry to a vendor reconciliation account because the posting run results for the off-cycle run were overlooked. Troubleshooting steps: Typically, most payroll users follow a standard checklist, similar to a pilot’s pre-flight checklist. It appears that the payroll user forgot a basic checklist item — to always check the result of the posting before sending out the payroll check from the off-cycle run. This problem could be caused by:

• Using a new or untested wage type that was not used before during off-cycle runs
• Some manipulative scenarios that payroll users sometimes use in payroll runs (e.g., infotype 0221 [runs])

To fix this problem, run a dummy (non-pay) off-cycle run to balance the documents and post them. This single off-cycle payroll is used to adjust the postings, but does not have any impact on payments to employees.

Cannot Reconcile Checks and Banks

Issue: After the regular payroll run is exited, bank reconciliation is run to ensure that all net payments for both the bank transfers and the printed checks are appropriately reconciled. Payroll users are typically in a rush to get the bank files to the bank and meet their deadlines, especially in weekly payroll situations. Therefore, these users tend to overlook reconciliation or miss it in some cases. Many payroll implementations do not carry out this step and, subsequently, have issues with missing checks, failed bank transfers, not paying an active employee, or mistakenly paying an inactive employee. Therefore the issue could be related to reconciliation of amounts or reconciliation of number of employees to be paid. Troubleshooting steps: Troubleshooting starts with checking the master data. You should:

• Double-check all active employees and their break-up of infotype 0009 for bank transfer and checks subtypes. You can very easily get this data through an ad hoc query.
• Run the wage type reporter with /559 wage types that are used in payroll cluster bank transfer (BT) tables. You need to watch out for the splits for /559 for employees who may have multiples of infotype 0009 distributions. You can display payroll results (using transaction PC_PAYRESULT) if you need to display contents of BT tables. Payroll journals can also be used to print BT details for employees.
• Reconcile the amounts between the data medium exchange (DME) and wage type reporter outputs
• Reconcile the employee numbers with infotype 0009 and the DME output

Incorrect Payment Wage Type

Issue: In my example, HR or payroll users do data entry in infotypes 0014 and 0015. Typically, in these infotypes a user selects a wage type from a drop-down list of permissible wage types in the wage type field. An HR user or payroll user chooses the wrong wage type in infotype 0015 to pay the employee. The taxation for this wage type was different from the one that was supposed to be used. This is likely to create an issue with taxation and the net payment for an employee. Troubleshooting steps: The wage types seem to be configured such that the user selects a wage type from a drop-down list and needs to know the right wage type based on a scenario. For example, the user is supposed to enter a one-time payment using infotype 0015 and a wage type in infotype 0015. The drop-down list gives a choice of five or six wage types. In the SAP system, it can be difficult to ascertain specific tax characteristics by looking at the wage type, unless the numbering and text are created with some discipline. To fix this situation, you can retroactively delete and change the wage type in infotype 0015 and inform the employee that the new result appears in the remuneration statement. Or, if the impact is only on taxation, then use infotype 0221 to fix the taxes and taxable base externally. Another simple tip is to take another look at wage types. Make sure that the wage types follow a numbering scheme based on earnings, deductions, pre-tax criteria, or post-tax criteria. It is also easy to add some description-specific text in wage type descriptions to assist users with the right selection of wage type.

A Single Group of Employees Was Omitted from a Payroll Run

Issue: One day after the payroll was sent out to employees, a group of employees from a single location complains that they did not receive their paychecks. Troubleshooting steps: This is probably the result of a violation of some best practices, such as not reconciling active employees, not reconciling time and payroll integration, or a lack of a business process to ensure that the location or site HR person checked the payroll results. To troubleshoot this issue, you should:

• Check payroll clusters and, if the payroll clusters themselves are missing /101 or /559 and have no pay for employees, inputs to payroll could be missing
• If these are hourly employees, look at the time data to find out if payroll received time evaluation clusters
• Check to ensure that the time data made it on time during the time evaluation and payroll runs

Once you have identified the cause of this issue, to pay this group, run an off-cycle correction run using the payroll driver.

Wrong Taxable Base

Issue: While running W2 simulations for year-end tax preparations, the payroll user noticed that the taxable base for some employees was incorrect. Troubleshooting steps: The taxable base can be run incorrectly for a few reasons:

• The wrong wage type configuration
• The state taxation rules and treatment of taxable base is different from the federal rules
• The gross-up or other taxation situations cause payroll maintenance teams to create one-off wage types in a hurry, which causes problems with the taxable base. (Gross-up refers to when an employer reimburses an employee for the taxes paid on some of their payments. Typically these are one-time payments. For example, when an employer needs to pay $4000 for tuition reimbursement but the check it issues is for $5112 based on “gross-up calculations,” i.e., $4000 plus $1112 in taxes.)

A useful reporting tool for avoiding this issue is a wage type utilization report (report RPDLGA20). With this report, users can see the taxation details (processing class 69, 71) for wage types. In some test cases, you may want to go across the payroll results and run W-2 simulations for sample employees and check the taxable base /6xx and /7xx wage types. For example, if the taxable base is incorrect or if there is an issue related to tax processing classes, W-2 simulation or a verification of taxable base is strongly recommended. You can also run reports such as the 941 report in tax reporter (in case you have a configured tax reporter in your implementation). Some of these tax reporter reports can help you with their ready-made formatted output in verifying the taxable and tax amounts.

Multi-State Taxation Issues

Issue: An employee works in New York and lives in New Jersey (neighboring states with tax reciprocity). The employee has to also work in a third state during the year. Let us also assume that that the third state is not close to New York or New Jersey and is not covered under reciprocity. The payroll system did not take into account the different tax deduction calculations that were triggered by the time spent in the third state. In this scenario, assume that the employee uses CATS to enter their working hours in the system. Troubleshooting steps: Since the payroll system is not deducting taxes for the work state, the basic question is, does the payroll system know that the employee worked in a third state that is not the permanent resident state nor the state where the job is located? Obviously, the payroll system needs to know the employee work hours in the third state. The SAP system relies on infotype 0207 (residence taxes) and infotype 0208 (work tax) for the calculations. The problem is that the employee is using CATS to enter time data; however, CATS is only capturing hours worked and not the work location. To solve this issue:

• CATS can be modified to accept additional work states (in addition to work tax infotype 0208) and then feed that data to payroll
• Alternatively, a simple solution is to use infotype 0208 (work tax) and create a record for the appropriate tax area. This infotype also has an allocation percent field that can be used. For example, let’s say that the employee works in this third state one day a week. Therefore, an infotype 0208 with a 20 percent allocation is created and the remaining 80 percent is allocated to the normal work state.

Missed an Inbound Interface

Issue: For this group of employees, an inbound interface brings in sales commission amounts. These amounts are loaded in infotype 0015 and employees are paid their sales commissions. Troubleshooting steps: To begin with, there seems to be a failure of good payroll business practices. These are:

• Payroll should check its operations list to ensure that this interface was successfully loaded
• The business process should be such that any errors that occur during this interface load are checked
• A pre-payroll preventive report on this wage type and infotype (0015) should also be able to catch the missed interface

To rectify the situation, you can:

• Either pay the sales commissions in the next payroll, retroactively
• Run a correction off-cycle run for this group of employees and pay them the commissions

Missed an Outbound Interface

Issue: After completing the payroll, an outbound interface was missed. In the meantime, the next payroll is run and the users realize that the interface did not go out for the earlier payroll run. Troubleshooting steps: There are three ways to correct this error:

• Automate the batch job to take away human intervention
• Add checks and controls in interface logic with the ability to take into account all off-cycle and regular payroll runs that were not sent out earlier
• Ensure that appropriate action is taken and communication is clear between the HR and payroll departments and external vendors or agencies to mitigate the impact on compliance or regulatory affairs offices

Checks Were Damaged When Printed

Issue: Some checks were torn during printing. This problem was not noticed in time and the paychecks were sent out. Therefore, it was not possible to reprint the checks in the same run. Troubleshooting steps: Use a replacement off-cycle run to reissue a new check.

New PCR Did Not Work (and Payroll Has Been Exited)

Issue: A new personnel calculation rule (PCR) was introduced during this pay period and was tested. The rule was supposed to handle a new wage type and calculate earnings for a group of employees, but it did not work. Troubleshooting steps: Use payroll simulation to analyze the rule and find out why it failed. It could be that the logic and decision criteria in the rule failed and hence the wage type was not written in the infotype tables. If you have already completed the payroll and exited the payroll control record, then, in the following pay period, you can retroactively force the payroll to go back to the previous payroll and correct the issue. If you detect the problem prior to releasing the control record, then you can rectify the rule in that pay period itself.

General Ledger Posting Error

Issue: You forgot to run the general ledger posting simulation run prior to exiting from payroll. After exiting payroll, errors were found in the general ledger posting run. There are several different errors that can occur during general ledger posting runs; therefore, the solutions are different as well. I list the issues and the corresponding troubleshooting steps and resolutions in the section below.

• Error 1: Cost center or work breakdown structure (WBS) errors
• Error 2: General ledger posting documents are out of balance
• Error 3: Configuration errors related to symbolic and general ledger accounts

Troubleshooting steps: Here are some steps to correct these issues:

• Resolution for cost center or WBS errors: Cancel the current posting run or delete it using transaction PCP0. In cases in which the finance and payroll systems are in separate instances (not in one application environment), the chances for such an error is greater. It is possible that the payroll system is using inactive cost centers since finance and payroll systems may be out of sync.
• Resolution of out-of-balance general ledger posting documents: Exclude the employees with errors and rerun the ones remaining so at least the majority of the payroll posting run gets out on time. Then reverse the original payroll run for selected employees and rerun the payroll run after correcting the errors. With this solution, you have to manually enter bank transfers and checks from the earlier run that were already sent out to employees.
• Resolution for configuration errors related to symbolic and general ledger accounts: These kinds of errors are found during general ledger posting simulations. To fix them, run the standard SAP system posting program RPCIPE00 before exiting out of payroll.

Integrating External Time-Clock Systems with SAP Payroll

Issue: Integration issues related to the time-clocking system top the list of issues, especially in newer implementations. In my example, the external time-clock system has an interface with the SAP payroll system and data is brought in using infotype 2010. The data is already evaluated by an external time system. (In some situations, the SAP system could do time evaluation, but in my example, the time-clocking system carries out time evaluation.) The issues with this are:

• How to ensure that all the data for active employees is flowing between two systems (reconciliation of employees between the time system and SAP ERP HCM)
• How to handle data errors and last-minute changes, especially ones due to interface schedules

Troubleshooting steps: Look for potential errors in the following areas:

• Status of employees in both systems could be misaligned due to late terminations or hires
• Validations and error checks during interface loading may not be sufficient
• Check to see if users have access to change-time data in the SAP system after it has been transferred from the time-clocking system (causing an out-of-sync situation between the two systems)
• Retroactive changes:
• Errors are sometimes brought in with the current date and can cause confusion
• New records that are supposed to balance old records (e.g., interfaces use negative or positive amounts)
  • Make sure that the employee numbers and amount totals are reconciled in both systems. This is an essential control mechanism prior to exiting payroll.

The Remuneration Statement Display Does Not Match the Payroll Result Tables

Issue: The remuneration statement looks different depending on the variant or the parameters used to run it. If the form is developed using transaction PE51, these variation errors are more likely to occur. In earlier SAP systems, development teams used transaction PE51 to develop remuneration statement forms. In more recent versions, users are moving toward using SAP Smartforms or SAP Interactive Forms by Adobe instead. This issue is more likely to occur with transaction PE51 forms. Troubleshooting steps: The display misalignments in remuneration statements can occur because of:

• A lack of standard use of evaluation class 02 for printing remuneration statements. Wage types need to be configured for use of evaluation classes for both remuneration statements and payroll journals.
• The totaling of the wage type in gross wages /101 and the totals in the form (e.g., sometimes the gross earning totals in the form may not match /101). Use wage type utilization report RPDLGA20 to confirm that /101 has all the right wage types cumulated in it.
• The printing of retroactive lines in the form with a lack of details (e.g., employees who are looking at remuneration statements may not know the effect of the retroactive change and how to read the statement). Ensure that detailed employee communication is sent out. This communication should explain the steps and give examples for reading and understanding the remuneration statement.
• The printing of /551 or /552 in forms can cause confusion if the retroactive differences are shown using those wage types. Remuneration statement forms should be configured to separately print the retroactive earnings and deductions with the details of the appropriate retroactive period. In some states, such as California, the regulations mandate that remuneration statements include retroactive details.

The remuneration statement is the one single output from SAP ERP HCM that touches every employee. Therefore, any changes to it (after the system is operational) need to be communicated well and then implemented at the right time. For example, imagine the first payroll of the new year. After implementing the new remuneration statement, payroll departments are able to rerun the payslips using an SAP system standard remuneration printing program such as report RPCEDTU0.

Issue Categories and Resolution Strategies

Using the examples discussed above, you can categorize a list of problems and their corresponding solutions. Creating a categorized list helps to establish a resolution path. Table 1 is a list of such categories and their resolution paths.