Understanding the integration between SAP Payroll and FI/CO is critical to ensuring that payroll is correctly accounted and reconciled. I'm going to describe the configuration options available in this integration area as well as their effect on R/3 HR Payroll-FI/CO reconciliation.

Just as various amounts and balances in FI/CO are stored in accounts, all the amounts and balances in payroll are stored in wage types. An employee's base pay, overtime, tax, deduction, and net pay amounts are stored in wage types, as are employer-paid items such as employer taxes and the employer portions of benefits. As in FI/CO account balances, the amounts in wage types are related to other objects such as cost centers, company codes, and business areas. Wage types are the central concept of SAP Payroll and are the primary integration point with FI/CO.

You need to understand six important topics to ensure a smooth, accurate, and complete integration between SAP Payroll and FI/CO:

• Mapping wage types to FI/CO accounts
• Overriding cost center assignments
• Generating intercompany postings
• Making date-effective changes
• Generating month-end accruals
• Ensuring all payrolls are posted to FI/CO

Map Wage Types to FI/CO Accounts

The process of mapping a wage type in payroll to an account in FI/CO requires four steps. In payroll, wage types are not mapped directly to FI/CO accounts. Instead they are mapped to a symbolic account in HR, and then that symbolic account is mapped to the FI/CO account.

The first step is to define symbolic accounts. A symbolic account is simply a four-character code defined in the Payroll IMG, as shown in Figure 1. To access this configuration table, select the IMG path Payroll>Payroll USA (or your specific country version of payroll)>Posting to financial accounting>Activities in the HR system>Symbolic accounts. This table applies to every payroll country. Many customers find it convenient to separate the symbolic accounts by country. For example, the HR country identifier for the US is 10. You can find the HR country grouping code for each country in configuration table T500L.

Figure 1

Define symbolic accounts

The AATyp column is for accounting activity type. It determines what type of FI/CO account the symbolic account is mapped to. Figure 2 on the next page lists the possible values for the accounting activity type. The most commonly used values are C and F. Some companies post their payroll net pay to a KF symbolic account, which creates a payable amount for a specific vendor number. Then the payable amount in that vendor number is included in their cash management process.

Figure 2

Accounting activity types

The last column of Figure 1 specifies whether the symbolic account needs to consider the type of employee being paid. For example, it is common to account for exempt employees' salaries in a different account than for non-exempt employees. In those cases, you select the check box that says this symbolic account is dependent on the employee grouping (the EG-depend. column).

In the second step of mapping wage types to FI/CO accounts, you define employee groupings for account assignment. The payroll posting process dynamically determines the employee grouping by using an HR feature named PPMOD when posting documents are created. The PPMOD feature is simply a decision tree that looks at the types of employees to determine what grouping to assign them. Figure 3 shows part of a typical decision tree in PPMOD. You look at the type of employee (the ABART field) and if it is 1, then you assign an employee grouping of 2. If the employee type is 3, then you assign grouping 1. If you see neither of those values, then you return an ERROR, which stops the posting process.

Figure 3

Determine employee grouping for accounting

In the third step, you map the wage type to the symbolic account, as shown in Figure 4. The V column can be a + or a -. The system multiplies the amount of that wage type by either +1 or -1 before posting. In some cases a wage type has a positive amount in the payroll results, but you want to post positives as credits in FI/CO. In those cases, set the V column to "-" (minus sign). For example, employee tax deductions are stored as positive amounts in US payroll, but you need to create credits in FI/CO. Therefore, you multiply them by -1 before posting. The Ign.CA column, if checked, ignores any cost center overrides entered on wage types or attendances/absences. Instead, it posts those expenses to the employee's home cost centers in infotypes 0001 and 0027. The ProcessTyp column defaults to Normal processing. I'll explain another common value, Month-end accruals, later in this article.

Figure 4

Map a wage type to a symbolic account

The fourth step is to map the symbolic account to the FI/CO account. Figure 5 shows the mapping of symbolic account 1000 to three different expense accounts, depending on the employee grouping.

Figure 5

Map a symbolic account to FI/CO account

Cost Center Overrides

While all employees have a default or home cost center, their expense-related wage types can have overrides that send them to other cost centers, even to cost centers in other company codes. You enter these overrides both at the employee level and on specific wage types or attendances/ absences. The overrides are then stored with the payroll results that are processed in the posting process to FI/CO. It is also possible to dynamically override cost centers during the posting process.

One option is to override the cost center for all amounts being charged to a specific cost element in a company code or business area. You do this via the Setup fixed cost postings in the Posting to financial accounting section of the Payroll IMG. Figure 6 shows an example in which all charges to cost element 5008640 in company code 1000 have an override cost center of 1001003. A company commonly does this when it wants to assign employee benefits to one specific cost center instead of having them hit the individual employee cost centers. A significant limitation of this functionality is that the override cost center has to be in the same company code. This functionality can't be used to trigger intercompany transactions.

Figure 6

Set a fixed cost center for a cost element

Another way to override cost centers is to set up substitute cost centers, as shown in Figure 7. If the payroll process tries to post to a closed cost center, then this substitute cost center is used instead. For example, a cost center was closed on January 31, but when the February payroll was run, it retrocalculated and found the employee's January overtime increased. Payroll charges the increase to January's cost center because that is where it was initially incurred. When the payroll posting runs, it produces warning messages for all cost centers that were substituted. While this makes the posting process proceed with fewer errors, you need to review the costs that end up in the substitute cost center and allocate them back to the proper places. Many companies decide not to use substitute cost centers as a way of forcing users to get the charges correct the first time.

Figure 7

Define a substitute cost center for HR postings

That sometimes means that you have to reopen closed cost centers for payroll posting. Both of these overrides can cause additional effort in reconciling payroll to FI/CO. Payroll reports report wage types in the cost centers in which they were paid. These reports have no visibility to the overrides that were done in the payroll posting process.

Intercompany Accounting

A common requirement in multicompany environments is to pay all the payroll net pay from one company's bank account. The payroll check and direct deposit programs support this "paying company" requirement, but the posting to FI/CO process does not. No standard method in the payroll posting process creates inter-company postings for financial accounts. Intercompany postings are triggered only when the posting program finds a cost center that is not in the same company code as the employee's home company code determined in infotype 0001.

A similar problem occurs when employee deductions are collected from employees in multiple company codes, but accounts payable wants to cut one remittance for all companies involved. This commonly happens with employee benefits such as 401(k) accounts. These amounts are deducted and posted by payroll to a liability account per company code.

Some companies want to restrict the ability to cross-charge expenses from one company to another. For example, companies don't want to cross-charge expenses between their operating companies and their trust companies (such as retiree trusts or trusts for long-term disability payments). No standard functionality in SAP HR prevents a user from cross-charging between two specific company codes. In my HR Expert article, "Control Cross-Company Accounting in SAP Payroll," I describe how to program a user exit to solve this problem.

Once the wage type to account mapping is completed, it is common to have additional corrections or additions to this configuration. Perhaps you want to change the account employer benefits are charged to, or you consolidate the accounts for payroll taxes. When you make a change to the Payroll-FI/CO integration, you always need to consider effective dates. You can make most changes in Payroll date effective. For example, the mapping of wage type to symbolic account shown in Figure 4 has an effective date. This is important because SAP Payroll often retrocalculates an employee. When it retrocalculates, the FI/CO posting program reevaluates each of those retroactive periods and posts any differences it finds. Normally this is not a problem, but when you make changes to the Payroll-FI/CO integration that are not date effective, you might see some unexpected activity.

For example, let's say your company mapped base pay to symbolic account 1000, and symbolic account 1000 was mapped to FI/CO account 5001000. When the payroll system posts payroll results to FI/CO, it records how much was posted to each symbolic account. If an employee was paid $5,000 in base pay for January, the system records a $5,000 debit to symbolic account 1000. Say on February 1 you change symbolic account 1000 to map to FI/CO account 5021000. Then payroll determines an employee was overpaid in January and the system automatically recalculates January's base pay as $4,000. It compares the original $5,000 recorded to symbolic account 1000 to the new amount of $4,000 allocated to symbolic account 1000, and creates a $1,000 credit for symbolic account 1000. Since there is no effective date on the mapping for symbolic account to FI/CO account, that $1,000 credit hits account 5021000.

If you want to make this a date-effective change, then create a new symbolic account 1050, for example, and map it to FI/CO account 5021000. Then in the mapping from wage type to symbolic account, make a date-effective change in the mapping of base pay. Through the end of January, it maps to symbolic account 1000, and from February 1 forward, it maps to symbolic account 1050. Then in this example, the $1,000 credit is made to account 5001000 instead of to 5021000.

Month-End Accruals

Most of the Payroll-FI/CO integration is not country specific, but you need to consider special functionality for the US when customizing the system and performing reconciliations. In the US, it is common to have weekly and biweekly payrolls that cross at the end of a month. Since R/3 normally uses the payroll check date as the posting date for accounting, many companies prefer to accrue parts of these payrolls to make expense accounting more even from period to period. For example, if five days of a biweekly period are in February and the other nine days are in January, a company may want to place nine-fourteenths of that expense in January and five-fourteenths in February. For the US, R/3 can automatically calculate and post month-end accruals via the payroll process.

You calculate the accrual factors per employee and can determine them three ways: calendar days, working days, or working hours. For working days and working hours, the payroll calculation looks at the employee's work schedule stored in infotype 0007. Configuration of month-end accruals is found in the Month-End Accruals section of the US Payroll IMG.

When the payroll system determines that a month-end accrual needs to be made, it calculates the factors for the employee and stores them in the internal table ACCR in the payroll result. When the posting program runs, it reads the factors in this table to create two additional posting documents — one for the current month and one for the next month. It uses the symbolic accounts specified for the month-end accrual process, as shown in Figure 4.

Some companies would like to assign a different document type to accruals so that they can be better identified and separated in FI/CO reporting. Unfortunately, this is not possible since the accruals are generated in the same process as regular payroll postings, and the posting variant specifies only one document type. When reconciling FI/CO back to payroll, you have to filter the accruals out of the FI/CO numbers because the payroll reconciliation report does not consider month-end accruals.

Ensure All Payrolls Are Posted

Another problem some companies find when reconciling payroll to FI/CO is that some payrolls are not posted. For example, an off-cycle bonus check was paid, but someone forgot to post it to FI/CO. Or because of incorrect configuration, a payroll result may have been paid but doesn't balance debit-to-credit and can't be posted to FI/CO. Sometimes you can resolve these errors and at other times you can't. If a payroll result rejects from posting because of such an error, it has to be manually posted to FI/CO. If any subsequent payroll result retrocalculates over this faulty one, then that current period cannot be posted.

For retroactive payroll periods, the payroll posting program compares what was posted originally to what ought to be posted now, and when the original posting was faulty, it can not determine what the changes are. When the payroll department initially finds such a faulty payroll result, it can prevent subsequent payroll periods from retrocalculating over it by updating the employee's infotype 0003. Figure 8 shows part of infotype 0003 for an employee, showing the earliest retroactive accounting date set to 02/01/2004. This prevents payroll from retrocalculating any payrolls prior to that date. This infotype also shows that payroll has been run through 03/31/2004. In HR/Payroll terms Accounted to and retroactive accounting refer to the creation of payroll results, not to the posting of payroll result to FI/CO.

Figure 8

Prevent retrocalculations on infotype 0003

R/3 provides transaction PC00_M99_CIPC, which is called the completeness check, that you can use to make sure every payroll result that has been created has also been posted to FI/CO. This transaction looks at every payroll dated after a certain date to see if it is related to a payroll posting document. If it is not, then it lists specific information to identify the personnel number and payroll result. Some payroll results do not result in any debits or credits, and in those cases the system doesn't create a posting document for those results. For example, payroll could make an adjustment only to an employee's taxable wages, which doesn't result in any FI/CO postings. These results are listed by the completeness check, so a user has to review each of these results to see if they simply did not have any debits or credits to post, or if they were indeed regular payroll results that did not get posted for some reason.

Two payroll practices can prevent payroll results from being paid but not posted. First, for regular payroll periods, the payroll department ought to always run the posting to FI/CO in simulation mode before finalizing the payroll and printing checks. The simulation run will identify any posting issues and payroll can fix the faulty payrolls. Once the payroll is finalized and checks are printed or direct deposits transferred, the wage types within each payroll result are frozen and can't be changed, which can make it very difficult to resolve posting issues.

Second, you can modify the SAP process model that performs all the subsequent activities for off-cycle payrolls so that it includes a payroll posting simulation. The process model then stops all subsequent processes if the simulation finds documents with an error. Figure 9 shows a Breakpoint used in the off- cycle process model that stops subsequent processing if the posting simulation document status is equal to 90, the code for incorrect documents. If an off-cycle payroll stops at this point, payroll sees the error in the HR Process Workbench (transaction PUST). The payroll department then can look at the spool output for that employee and analyze the error. Once the error is corrected, it can restart the process. If the posting simulation is successful, then the remaining steps, typically check printing, third-party remittances, and the production posting to FI/CO, can proceed.

Figure 9

A Breakpoint stops subsequent processing

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.