In R/3, fields that are calculated, such as the amount of a benefit deduction, are not stored directly in the database. Rather, the underlying data required to make the calculation is stored and the amount is calculated in real time as needed. This allows R/3 to calculate the correct deduction even when some related data has been changed, but it can sometimes lead to perplexing results.

In benefits, cost information is presented in terms of expected or estimated amounts. A complex set of interrelated factors comes into play during payroll processing that can cause the actual deductions to be different. This article examines the integration between payroll and benefits so that you can explain to your end users why this happens. You will understand which part of a deduction calculation happens in benefits and which part happens in payroll. The information presented in this article is based on U.S. Payroll, but many of the concepts are relevant in all countries.

Setting Deduction Rules in the Benefits Module

The benefits functional analyst enters coverage, cost, or contribution rules for each benefit plan. The configuration of these rules is based on benefit cost sheets produced in the corporate benefits office. These rules are executed in combination with employee demographic data each time a benefit deduction amount is needed. Several factors affect the calculation:

• The configuration of benefits plans. The benefits department sets forth specific employee and employer cost figures for each plan and option. These amounts are contained in the cost, coverage, and contribution rules of the IMG. The rules have begin and end dates, allowing for changes over time. The configuration is done in several steps under IMG menu path Personnel Management > Benefits Administration > Plans.
• The employee’s current master data. Master data records hold the employee’s elected coverage plans and options. These records also have begin and end dates. They are created in benefits enrollment transactions, through Employee Self-Service, or manually via transaction code PA30.
• The evaluation date. Since each of the previous items changes over time, you must specify an evaluation date when calculating the cost of a benefit plan. This date is used to identify the employee’s election and then determine the cost. Any data required to make the calculation, such as the employee’s age, is determined on the evaluation date.

In the enrollment transaction, the evaluation date is called the Enroll On date, and on the infotype screens it is called the Calculation Date. The master data and the configuration rules are both accessed using the evaluation date to determine the deduction amount.

Transactions in the benefits module and benefits infotypes in the personnel administration module all display benefits plan cost information. Health, insurance, and credit plans display an estimated deduction amount. Savings and spending plans, however, display the elected percentage or goal amount because the deduction amount is dependent upon actual payroll results. Deduction amounts displayed within the benefits transactions are estimates only. Actual deductions in payroll vary based on actual earnings and deduction rules.

These basic factors apply to all benefits plans. However, there are some differences in the way that deduction amounts are calculated for each plan category.

Health Plans

The cost of health plans is calculated based on the plan, option, and dependent coverage level selected by the employee. These values from the master data are compared to the configuration for the plan to calculate the employee and employer cost amounts. Additional factors can be salary, age, seniority, cost grouping, gender, and tobacco usage.

Insurance Plans

A two-step process determines the cost of an insurance plan. The first step is to determine the dollar amount of coverage offered by the plan. The insurance option from the master data is compared to the coverage rules configured for the plan in order to calculate a coverage amount. Data used in the formula can include salary, age, seniority, and coverage grouping. The second step is to apply a cost calculation rule to the coverage amount. In this step, the employee and employer costs are determined. Indicative data can include salary, age, seniority, cost grouping, gender, and tobacco usage.

Savings Plans

Unlike health and insurance plans, the amount of a savings plan contribution cannot be calculated outside of payroll. This is because the amount of a savings plan deduction is dependent on qualified earnings. Salary, age, seniority, and contribution grouping can be used in the contribution rules.

Flexible Spending Plans

Flexible spending plans differ from other types of benefits because the employee elects an annual contribution goal rather than a per-pay-period amount. R/3 calculates a deduction amount each pay period that allows the employee to reach the goal as evenly as possible by year’s end. Confirmation letters and enrollment forms display the annual goal because the per-period amount can vary.

Calculating the Deduction Amounts in the Payroll Module

When actual deductions are calculated as part of payroll, it gets more complicated. The configuration and master data are still key parts of the formula, but additional factors can affect the benefit deduction amounts. Every pay period has a begin date, an end date, and a check date. The determination of applicable master data is based on one or more of these dates. Each plan category may use a different date selection. Other factors that can affect deduction amounts in payroll are the employee’s qualified earnings, available net pay, and prior contributions.

The integration point between payroll and benefits is contained in two schemas, named UBE1 and UBE2 in the default configuration (Figures 1 and 2). These may have been replaced by local versions in your system.

Figure 1

Schema UBE1 (benefits processing part 1)

Figure 2

Schema UBE2 (benefits processing part 2)

Within these schemas, payroll functions are called to process each plan category. The function P0167, for example, is called for health plans. These functions each accept one argument, called DATES, to determine the evaluation date of infotypes. The possible values are defined in Table 1.

The payroll functions select master data first. Using the DATES parameter (Par1 in Figures 1 and 2), the function determines which master data records are used to calculate a deduction. All parameters other than PER select only one master data record per plan type. The PER parameter selects all records that are valid in the pay period.

Once a master data record is selected, the payroll function determines the evaluation date. The cost of a plan is always calculated on a particular date. When the DATES parameter has a value of BEG, BEGT, END, or CHK, the evaluation date is the pay period begin date, end date, or check date, respectively. When the DATES parameter has a value of FRST, LAST, or PER, the evaluation date is the infotype record begin date or the pay period begin date, whichever is later.

The payroll function then calls a benefits function to determine the desired deduction amount. The evaluation date, along with other information from the current pay period, is passed to the benefits cost function. A different cost function exists for each plan category. Each works slightly differently.

Health and Insurance Plans

The desired deduction amount for health and insurance plans is calculated by using the benefit plan record and the evaluation date. The benefits cost function determines any other required demographic data, such as age or salary on the evaluation date. For these plan categories, the desired cost calculated in payroll is always the same as the cost displayed on the infotype. Display the cost tab on the infotype record using the same evaluation date when investigating a health or insurance plan deduction.

Savings Plans

Savings plan contributions are often a factor of qualified earnings. Earlier steps in the payroll process calculate the qualified earnings and store them in a wage type called the technical base wage type. The standard technical base wage type for savings plans is “/102.” All earnings (wage types) that qualify for the savings plan are configured to accumulate to the “/102” wage type in gross payroll processing. The P0169 function in payroll passes the technical base wage type amount to the benefits cost function. This information is combined with the benefit plan and configuration valid on the evaluation date to arrive at a desired deduction amount and employer contribution. Unexpected savings plan deduction amounts are often caused by variations in qualified earnings. Examine wage type “/102” on the final RT table when investigating a savings plan deduction.

Spending Plans

The desired deduction amount for spending plans is dependent on the annual goal and prior contributions. A table in Payroll called BENTAB tracks year-to-date contributions and claims for spending plans. The payroll and benefits integration function for spending plans uses this table and the related master data to determine a contribution amount. The calculation is:

current deduction = (annual goal from
infotype 170 – YTD contributions from
BENTAB) / number of remaining
deduction periods in year.

When an employee elects an annual goal at the beginning of the year and makes full contributions each pay period, the deduction remains constant. When employees change their annual goal partway through the year or get behind on contributions, the per-period amount is adjusted. Each pay period, R/3 determines how much of the goal has yet to be paid and spreads that amount evenly over the remaining periods. This self-adjusting nature of spending plan deductions is often a source of confusion. Look at table BENTAB in the payroll results when investigating a spending plan deduction.

It is most common for payroll function P0170 to be called using DATES parameter value CHK. This is consistent with the fact that pay periods are assigned to tax years based on check date and annual spending plan elections are distributed across the deduction periods of the year.

Changes to the Deduction Amounts Later in Payroll

Arrears processing and retroactive accounting can cause the final deduction amount to vary from the desired deduction amount. These adjustments can be difficult for either the benefits department or the payroll department to explain, because the ultimate amount is a combination of calculations from both functional areas. The payroll functions such as P0167 obtain the desired deduction/contribution amounts from appropriate benefits functions. Later, the payroll function PRPRI may reduce the desired amount. PRPRI evaluates the priorities of deductions and determines if enough net pay remains to take all deductions. The disposition of a deduction that cannot be taken is handled according to the configuration of table T51P6. Untaken amounts can be either ignored or placed on the arrears table for later collection. The configuration on table T51P6 should take into consideration company policy as well as the nature of each plan category.

Health and Insurance Plans

Most companies wish to collect the full amount of health and insurance premiums. For this reason, the standard R/3 configuration for health and insurance plan deductions collects as much as possible in the current period and puts the remainder in the arrears table. This configuration applies only to the employee portion because no net pay is required for the company to pay its share.

Savings Plans

When a savings plan deferral amount is adjusted in PRPRI, the adjusted amount is passed through the BENMA function to ensure that company match money is correct. For example, say an employee has qualified earnings of $1,000 and a 10 percent deferral election. The company match is 100 percent of the first 5 percent. Given these parameters, the desired employee contribution is $100 and the desired company match is $50. Assume that deductions of higher priority have reduced the available net to $40. Function PRPRI changes the $100 desired deduction to a $40 actual deduction. Then function BENMA changes the desired $50 match to $40. The employee actually contributed 4 percent of qualified earnings and is entitled to a 4 percent match.

Your company may wish to allow this employee to contribute the remaining $60 in a later pay period. You can do this by specifying that the remainder go to arrears. Amounts that go to the arrears table are no longer treated as “benefits” deductions. They are simply amounts connected to a wage type that will be collected when enough net pay allows it. The $10 desired company match would not be paid because there is no longer a connection between the arrears amount and the benefit plan configuration.

If the net pay was low because an earnings item was missing, it is possible for the full company match to be calculated. Enter the earnings information with an effective date in the original period. This forces retroactive accounting of that period. The employee and employer amounts will be recalculated and paid in full.

Spending Plans

Standard R/3 configuration for spending plan contributions excludes them from arrears processing. This is because the desired amount is self-adjusting and already takes prior contributions into consideration. In general, spending plan contributions are configured to take as much as possible and forget the difference. The amount not contributed is spread out over the remaining deduction periods of the year.

Recovery of Arrears

Deductions that were not taken and were placed on the arrears table in a prior pay period will be taken in the current pay period if there is enough net pay. This arrears recovery amount is in addition to the desired current deduction. Wage type classes with limits can be configured to distribute the recovery process over several periods. This keeps an employee from getting a $0 net check after returning from leave.

Investigating Unexpected Deductions

The exact reason for any benefit deduction amount can be understood if you simply follow the steps used by R/3 in the calculation process. Keep the unique processing characteristics of each plan type in mind as you follow these steps.

• Obtain the pay period begin date, end date, and check date. Check the payroll schema to determine the DATES parameter used for the plan category. Use this information and the master data to determine which benefit plan record was used and what the evaluation date was.
• Examine amounts on the ARRRS table from the prior pay period. For spending plans, get the amounts from the prior period BENTAB table. This tells you how prior contributions/ deductions may affect the current result.
• Look at the ARRRS and DDNTK tables in the current period to see if any desired deduction amounts were not taken. For savings plans, look at the value of “/102” in the RT.

Example Selection Process

Let’s take the example of an employee enrolled in four health plans (Figure 3) to illustrate how the DATES parameter affects master data and configuration selection, and thus the amount of the deduction.

Figure 3

Calculating benefit deductions

The employee’s Plan 1 is a medical plan. It has a begin date before the start of the current pay period and continues beyond the end of the pay period. Plan 2 is a dental plan. It begins on day 5 of the current pay period and extends beyond the end of the pay period. Plan 3 is a vision plan. It has a begin date earlier than the beginning of the current pay period and ends on day 4 of the current pay period. Plan 4 is a cancer supplement plan. It has a begin date before the start of the current pay period and continues beyond the end of the pay period, but has a change of option on day 5 of the pay period. All plans and options are configured with a change of cost effective on day 6 of the pay period.

When the payroll and benefits integration function has DATES parameter value BEG or BEGT, the following selections are made: Plan 1 option A is evaluated on day 1 of the pay period. Plan 2 is not selected. Plan 3 option A is evaluated on day 1 of the pay period. Plan 4 option A is evaluated on day 1 of the pay period and plan 4 option B is not selected. The old costs are used for these plans.

Using DATES parameter value END or CHK results in the selection of plan 1 option A, plan 2 option A, and plan 4 option B. The price of these plans is evaluated on day 7 of the pay period for parameter END and on day 10 for value CHK. The new costs are used for these plans.

DATES parameter value FRST selects the first master data record in the pay period. The evaluation date is either the beginning of the infotype or the first day of the pay period, whichever is later. The resulting selections are plan 1 option A evaluated on day 1 (old cost), plan 2 option A evaluated on day 5 (old cost), plan 3 option A evaluated on day 1 (old cost), and plan 4 option A evaluated on day 1 (old cost).

DATES parameter value LAST selects the last master data record in the pay period. The evaluation date is either the beginning of the infotype or the first day of the pay period, whichever is later. The resulting selections are plan 1 option A evaluated on day 1 (old cost), plan 2 option A evaluated on day 5 (old cost), plan 3 option A evaluated on day 1 (old cost), and plan 4 option B evaluated on day 5 (old cost).

DATES parameter value PER selects all master data records that are valid in the pay period, and prorates the cost. The evaluation date is the beginning of the infotype or the first day of the pay period. The resulting selections are as follows: Plan 1 option A is evaluated on day 1 (old cost) of the pay period. The new cost does not affect this plan deduction until the next pay period. If your configuration includes a change of benefit cost in mid-pay period and you wish these new prices to take effect in that pay period, you must copy all the related infotype records with a new begin date on the first day of the new prices. Plan 2 option A is evaluated on day 5 (old cost) of the pay period and 3/7th of a deduction is calculated. Plan 3 option A is evaluated on day 1 (old cost) of the pay period and 4/7th of a deduction is calculated. Plan 4 option A is evaluated on day 1 (old cost) of the pay period and 4/7th of a deduction is calculated. Plan 4 option B is evaluated on day 5 (old cost) of the pay period and 3/7th of a deduction is calculated.

Clay Molinari

Clay Molinari has 20 years of experience in the IT industry and has been working as an SAP HR consultant since 1997. He is currently president of C&C Savant, Inc., an SAP consulting firm that specializes in combining standard SAP configuration and custom ABAP programming to help its clients solve unique or complicated requirements.

You may contact the author at claymolinari@comcast.ne.

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