The integration between SAP Payroll and SAP FI can be a problem for some companies. To make the integration work correctly, people need to know about both payroll and accounting and be able to speak in SAP terms about both subjects. That is an uncommon skill set. I'm going to present a basic overview of the integration from Payroll to FI. Subsequent articles will provide more detail about integration, implementation, and management. Figure 1 presents an overview of creating payroll results and posting them to FI.

Figure 1

Overview of payroll posting process

The four major processes that create postings from Payroll to FI are: current-period payrolls, third- party payments, payroll retrocalculations, and intercompany payroll charges. An effective way to understand the relationship between Payroll and FI is to map the payroll transactions to their corresponding FI accounts.

Current-Period Payrolls

For the base scenario, let's pay an employee as specified in Table 1. A payroll result is simply a collection of wage types. Wage types are codes created in Payroll configuration that carry various types of payments, deductions, taxes, etc. When employees look at their pay stubs, all the items are stored in payroll wage types. Wage types are also mapped to FI accounts. Notice that the positive or negative sign on the wage type amount doesn't necessarily correlate to a debit or credit; that is controlled via Payroll configuration.

The way Payroll handles net pay is not the same as how Accounts Payable (FI-AP) handles vendor checks. FI- AP has a process for clearing paid checks against a liability account, but that process does not exist in the standard R/3 Payroll system. The Payroll module simply posts the net pay to an FI account. If you pay all your employees via direct deposit, also called bank transfers, then this is not a problem. However, for employees paid via check, the Payroll module does not manage the clearing of checks against a net payroll liability account.

Third-Party Payments

If the payroll department is using R/3's third-party remittance functionality (3PR) to automate the payment of third-party liabilities such as taxes and 401(k) deductions, then when those items are due, the posting in Table 2 is created. If 3PR is not being used, then payroll has to run reports to determine the amount to pay and create manual FI-AP transactions, or process those deductions as external bank transfers. 3PR is available only for the US and Canada.

The 3PR posting process creates an open item on the vendors, which is picked up when FI-AP runs the payment program. The timing of the 3PR payments is controlled in payroll, not in FI-AP. For example, some tax authorities need their payments by the end of the month, while your 401(k) vendors most likely want their payment by the check date of the payroll. In some cases, tax remittances are due monthly, except when they cross a threshold, after which they are due immediately. The 3PR process in payroll monitors those due dates and sends the payments to FI-AP.

Payroll Retrocalculations

The R/3 Payroll module has the ability to recalculate previous payroll periods and roll the differences to the current payroll. For example, suppose in the example in Table 1 that someone forgot to update the employee's records to reflect that he was on an unpaid leave of absence. Since that was not recorded, he was incorrectly paid. When the next payroll period is run, the payroll system automatically calculates the amount the employee owes back to the company, as shown in Table 3.

For retrocalculated periods, payroll posts the differences between the previous result and the current one. In my example, the first time period 1 was calculated, I posted the results in Table 1. Table 3 shows the recalculated period 1. Since the employee should not have been paid, the base pay is reduced to zero. But, since I deducted and remitted employee taxes and the 401(k) deduction, those amounts do not change. Likewise, net pay has already been paid, so you cannot take it back. To balance out the decrease in base pay, R/3 creates a wage type called retro difference to balance out the pay period. The payroll module will not post a payroll period whose debits and credits do not balance.

That retro difference amount is rolled into period 2 with the sign reversed. R/3 tries to deduct that amount from whatever is being paid in that period. Since the employee is still on unpaid leave, there is nothing to deduct from, and the payroll system creates a claim wage type. A claim — an amount the employee owes back to the company — is typically booked to a receivable account.

Now let's assume that the employee returns from unpaid leave in period 3, and you pay him $1,500. Table 4 shows that payroll result and its FI transactions. This is a simple case for employee claims. In some cases, the employee never returns to work, never repays the claim, or repays part of it. Payroll could setup a repayment plan or it could write off the claim.

Intercompany Payroll Charges

In a multi-company environment, an employee's labor could be charged to more than one company. For example, you could have an employee whose home company assignment is Company A, but who is on loan to Company B for a special project. The payroll expenses would be charged to Company B, but taxes, deductions, and net pay (all FI accounts) continue to be charged to Company A. You have two options to set up the intercompany payroll accounting process.

The first option is the default delivered by R/3 in the Payroll module. It simply posts the lump sum of intercompany transactions to what is called a technical account. This technical account is also used to balance different types of documents. For example, when posting 3PR documents, both vendor and FI accounts are used. Since those two types of accounts cannot exist in the same document, two documents are created. One holds the debit to the payable account and a credit to the technical account, and the other document holds a debit to the technical account and a credit to the vendor account.

The second option is to post using the intercompany clearing accounts defined in FI. With this option, the documents in HR contain employee-level detail. This method also separates intercompany transactions from the lump sum technical accounts, which are still used to balance 3PR postings. Both of these features help make it easier to reconcile payroll accounting.

This functionality is determined by the posting variant configuration, as shown in Figure 2. Posting variants also control the document type and other attributes specific to FI postings. When the payroll results are posted to FI, and when 3PR postings are run, a specific posting variant is entered in the selection screen to control the posting behavior.

Figure 2

Maintain posting variant in Payroll section of IMG

Reconciling Payroll to FI/CO

A few complexities in reconciling the payroll results to FI accounts need to be considered.

Most companies post payroll results by the payroll check date. A payroll check, or direct deposit, with a settlement date of July 2 would be posted in period 7 in FI (assuming a calendar-year basis), even though the period-end for that payroll is June 27 and the payroll itself may have been calculated June 28. Issues in the payroll calculation or with employee-related data may cause delays in posting payroll for a few employees. Suppose in this case that the payroll check date was June 30, and an employee received the paycheck on that date. However, a configuration problem kept payroll from posting that result to FI. By the time the error was resolved, June had been closed in FI. At this point, payroll has to override the posting period for this paycheck to July so that it posts. When reconciling payroll to FI, payroll reports this as a June transaction but it shows up in FI as a July transaction.

Some companies use the wrong payroll reports in their reconciliation. In the US, the only report that should be used when trying to reconcile payroll to FI is the Payroll reconciliation report; it is the only report that correctly considers the payroll results in the same way they were posted. Payrolls for other countries can have some success using the wage type reporter because they do not have the same complications as does the US. In the US, payroll reconciliations have to consider voided and reversed paychecks, retrocalculations on taxes and claims, and off-cycle payrolls. Figure 3 shows the payroll area menu and transaction codes for these reports.

Figure 3

Payroll reports

Intercompany postings can also present a challenge to reconciliations. Suppose an employee in Company A has a special bonus paid and charged to a cost center in Company B. After that payroll is run, two posting documents (one for each company) are created and posted to FI. In the Payroll module, the reconciliation reports are run separately for each company. The report for Company B will not list the bonus paid to the employee in Company A, because it selected only employees assigned to Company B. The report for Company A will list, in a separate line, that bonus charged to Company B because it was paid to an employee in Company A.

Steve Bogner

Steve Bogner is a managing partner at Insight Consulting Partners and has been working with SAP HR since 1993. He has consulted for various public, private, domestic, and global companies on their SAP HR/Payroll implementations; presented at the SAP user's group ASUG; and been featured on the Sky Radio Network program regarding SAP HR.

Steve will be presenting at the upcoming HR Payroll Seminar November 7-8 in Chicago and November 27-28 in Orlando. For information on the event, click here.

You may contact the author at sbogner@insightcp.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.