Of all the questions and issues I hear from SAP US Payroll customers, claims processing seems to be the most persistent. People often ask, “What are claims? How are they created? How do we get rid of them? How do we set up our SAP Payroll system to handle them?”

Claims clearing can be complicated, and the process requires a substantial amount of careful configuration. If you skip one piece of the process or incorrectly configure key aspects of the wage types, then you may have a difficult and confusing time trying to clear the claims. I’ll explain the basics of claims processing via a simple example. All SAP US payrolls face this issue.

How Are Claims Created?

Let’s use the example of employee X, who was overpaid $100 and then terminated. The employee was gone by the time the company noticed the overpayment. SAP Payroll tracks that overpayment claim in the employee’s payroll results as wage type /561. The system generates the claim when the wage type representing the $100 overpayment is reduced. When the payroll recalculates that retroactive period, it generates the claim wage type.

Figure 1 shows this example using the Wage Type Reporter (report H99CWTR0). Employee X was hired on January 1, 2005, paid on a semi-monthly basis with a salary of $2,100.00 The employee was paid for period 1 (In-Period 200501 and For-period 200501), and then terminated.

Figure 1

How Payroll creates a claim

The HR team discovered that the employee was hired at the wrong salary, so it reduced infotype 0008 from $2,100.00 to $2,000.00. When the Payroll system calculated the period 2 payroll, it reduced employee X’s salary by $100.00. Nothing in period 2 offset that $100.00 reduction, since the employee was terminated. The payroll calculation automatically created the claim wage type /561 to balance it out.

You can look at this example using transaction PC_PAYRESULT to see where SAP stores the overpayment data. Figure 2 shows that in the retroactive period, In-Period 200502 For-Period 200501, table XDFRT contains all the taxable wage types with their values before and after the recalculation. Wage type 0SRG was $2,100.00 (the accounted amount) and is now $2,000.00 (the unaccounted amount).

Figure 2

Table XDFRT shows retroactive differences

In the current period, In-Period 200502 For-Period 200502, the payroll calculation tries to recover the overpayment. If it can, the system automatically moves the XDFRT entries to the BAL table, because the retroactive differences were balanced against the current period. If the system cannot recover the overpayment, the XDFRT entries are moved to the UNB table to reflect that the payroll is unbalanced. The BAL and UNB tables have the same layout and format structure as XDFRT.

Since no money in period 2 balanced out the overpayment, payroll creates the Claim wage type /561 in the results table (RT), as shown in Figure 3. It also creates a wage type /5PY, called Good Money. This wage type represents the amount of taxable income in the current period against which retroactive taxable differences can be offset. As long as it is negative, no taxable wages can be offset. In my example, the value of -100.00 reflects that the employee was overpaid by $100.00 in taxable money.

Figure 3

Claim and Good Money in table RT

Employee X did not pay back the claim, so the employee’s taxable wages are not reduced. Although the Payroll system reduced the year-to-date salary to $2,000.00 from $2,100.00, taxable wages remain at $2,100.00. If the claim is recovered in a subsequent period, the system will reduce employee X’s taxable wages. This could happen in the next month, quarter, or even the next tax year. Because it could happen in the next tax year, many payroll managers like to clear all the claims before year-end so that taxable wages and paid wages balance out.

How Are Claims Cleared?

Claims are the highest priority deduction in the payroll. Payroll deducts claims from the next available money paid to the employee. Let’s rehire employee X on March 1, 2005, and resume paying his salary. When payroll runs for period 5, it clears the claim. Figure 4 shows wage types from the RT involved in the cleared claim.

Figure 4

A cleared claim

Wage type /101 reflects that the employee was paid $2,000.00 in period 5, which is his normal salary. Wage type /563 is the claim amount from the previous period. This comes from wage type /561 from period 2 in this case, since that was the last time he was paid. Wage type /561 does not exist in period 5, which shows that the full amount of the claim was paid off. By subtracting the amount in wage type /561 from the amount in wage type /563, you can determine by how much the claim was reduced. In this case, it was eliminated.

Figure 4 also shows wage type /301, one of the wage types for taxable wages, with a value of $1,900.00. This reflects the $100.00 reduction of the $2,000.00 salary. The SAP Payroll system automatically reduces the employee’s taxable wages whenever it can recover the claim. Finally, wage type /5PY shows that the payroll result could be reduced by another $1,900.00 in taxable wages if needed. It was already reduced by the $100.00 claim. Wage type /5PY is the total amount of taxable income that could be reduced in the current period.

This is the simple case, but what if employee X didn’t return? In that case, you can collect the overpayment via a personal check, or you can write off the claim as a bad debt. In either case, it is highly recommended to use SAP’s claims clearing process for these transactions. It is part of HR/Payroll, but since it is in Payroll and involves money, the results post to FI/CO eventually.

SAP R/3 provides a report (RPCLMSU0) for identifying the components of a claim. For example, you would likely ask the employee to pay back only the net amount of that $100.00 overpayment. Determining that net amount can be complicated, so SAP R/3 provides a report that does the work for you.

This report is not currently available for Payroll in a concurrent employment environment. For details on how to manually identify the claim’s components, refer to SAP note 750057.

Configure the Claims Clearing Process

You have three areas to configure for clearing claims. First, you must configure the Off-Cycle Workbench and its follow-up activities. Eliminating the claim depends on being able to run off-cycle bonus checks. Most companies already have this set up and operational, so I won’t go into those details. Then you configure the claims reports and the claims clearing wage types.

Configure the Claims Report

The second item to configure is SAP claims clearing report, RPCLMSU0, or transaction PC00_M10_CLAIMS. This report identifies the components of a claim by running a payroll simulation with a special claims schema. (A schema is a collection of functions.) The first step is to create the claims schema that this claims clearing report uses.

The claims schema should be exactly the same as the normal payroll schema, with two modifications in the subschema used for taxes. SAP’s standard tax subschema is UTX0, but many companies copy UTX0 and customize it. Schema customization is common for configuring SAP Payroll to suit a company’s specific needs. The standard approach is to copy UTX0 and modify it rather than change SAP’s standard schema.

You go to the schema editor PE01, in the company’s tax subschema. Just before the schema calls the UPAR1 functions, insert the UTWE function. This tells the payroll driver to perform the tax calculation on a taxed-when-earned basis, instead of the normal taxed-when-paid basis. Second, comment out (put a * character in the D column) the UTPRI function, which is a US Tax PRIority, a function in the schema. In a standard payroll schema, the UTPRI function may change the taxes returned from SAP’s third-party tax calculation service, Business Systems, Inc. (BSI). However, for clearing claims you need to know the tax amounts without such modification. You can use the standard schema UTXC as an example.

One of the problems with having two schemas, one for regular payroll and one for claims processing, is that they can get out of sync if people don’t remember to maintain them both. You can combine the two schemas with a little effort.

The goal of this configuration is to create one main schema used by both regular payroll and the claims report. When running the schema for the claims report, you set a variable to be used as a flag for executing the UTWE function and skipping the UTPRI function. When the regular payroll schema is run, that variable is not set, causing the UTWE function to be skipped and UTPRI to be processed.

First, comment out the subschema for payroll initialization, typically UIN0 or ZIN0, in your main payroll schema. Then, create another executable schema using the schema editor via transaction PE01. Add two lines to it, as shown in Figure 5. First, call the initialization subschema UIN0, and then call the main payroll schema ZUA1.

Figure 5

Create a new payroll schema for claims

For the claims schema shown in Figure 6, which you get to via PE01, copy schema ZUAT to ZUAC using the schema editor’s copy function. Add a variable via a custom rule to indicate that you are processing claims. Payroll rule ZUAG has one line with two operations: AMT=1.00 and ADDWT&CLMS. This creates a variable called CLMS.

Figure 6

Copy schema ZUAT to ZUAC

Since the changes needed for claims processing are in the tax subschema, you can find the variable there. If the variable is set, call the UTWE function and skip the UTPRI function, as shown in Figure 7. On lines 000100 and 000190, the IF function is called with rule ZUAH, which looks at variable CLMS and returns a FALSE if the value is zero. Rule ZUAH is shown in Figure 8. The AMT field is set to the value of variable CLMS, and then compared to zero. If it is equal to zero, the system executes line 000030, returning a FALSE value to the IF function that called the rule. Otherwise, the TRUE condition is returned to the IF function.

Figure 7

Tax subschema with decisions for claims processing

Figure 8

Evaluate the value of variable CLMS

When the system calls this tax subschema via the main ZUAT schema, rule ZUAG isn’t processed. This means that variable CLMS has a value of zero when examined in rule ZUAH.

Now that you’ve created the claims schema, you need to create a variant for the payroll driver RPCALCU0 that calls that schema. Be sure to click on the Test run check box. None of the other optional settings in the payroll driver selection screen need to be set. Then use the feature editor PE03 to edit feature CLMPC and specify this as the variant to use for the claims report, as shown in Figure 9. Always remember to activate features after editing them by clicking on the matchstick icon or pressing F6. 

Figure 9

Specify variant for claims schema

To identify which employees have claims, use the wage type reporter (report H99CWTR0 or transaction PC00_M99_CWTR) and find those employees who have wage type /561. You could also run the payroll reconciliation report (RPCPRRU0, transaction PC00_M10_REC) to select and report wage type /561 only from the last payroll result. Don’t use the claims report because it performs a payroll simulation for each employee and is quite resource intensive when run for many employees at once. 

Configure the Claims Clearing Wage Types

Table 1 shows the many wage types you need to create and configure that support the claims process. SAP claims processing requires a separate wage type for each tax class that is represented in the claim. The claims report output in Figure 10 has a column in the Taxable Repay Amounts for proc. class 71, which is another term for the tax class. A tax class represents a unique way of taxing a wage type in any given tax authority. You define each tax class during the implementation project. 

Figure 10

Output of the claims report

Report RPDLGA20, or transaction PC00_M99_DLGA20, can determine which tax classes your SAP R/3 system uses. Run the report for wage types 0001 through 9___, which is the highest wage-type identifier that is possible in the system; 9___ eliminates all the model wage types delivered by SAP from the report. Whether running the report with the output in tables or the tree structure, you can navigate to processing classes and then to processing class 71 to see which tax classes the system is using. You need to create a claims clearing wage type set for each of these tax classes because claims are cleared by tax class.

The easiest way to create these claims schema wage types is to copy them via transaction OH11 from your existing wage types that have the same tax classes. In my example, wage type 0SRG has a tax class of 1, so you could use it as the source for creating 9FE1 and 9RE1. The same follows for the other earnings and deductions. Note that some companies may have more or different tax classes than others.

Once you copy the wage types for the claims schema, you need to check several settings to make sure they are processed correctly. When a claim is created, the payroll reduces expenses, usually represented as earnings wage types, and increases a receivable, which is mapped to the claim wage types /561 and /563. When you forgive or repay a claim, make sure the correct accounts are updated, as shown in Table 2. 

Some companies decide to display the claims clearing wage types on the payslip, and some don’t. Your payslip may select wage types based on the evaluation class 02 values, or the wage types may be hard-coded into the form. In any case, you probably won’t want them to appear in the same place as the wage types you copied from because clearing a claim is not the same as earning money and it’s confusing to the employee. Therefore you have to change evaluation class 02, in view V_512W_O, for example, or by changing the HR form used for your payslip via transaction PE51.

Each set of wage types also has to be available to be entered on certain infotypes. Use view V_T512Z to make sure the infotypes can be entered according to Table 3. Use transaction SM30 for view maintenance.

Finally, every wage type that is processed on infotype 0221 (Payroll adjustments) must have a value for processing class 82. This processing class determines how to handle override cost assignments, and can be maintained via view V_512W_O for the selected wage types.

My next article will provide an overview of the claims clearing process and advanced claims techniques.

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.