Defining Retroactive Processing for General Ledger

Retro presents special challenges in General Ledger, since incorrect setup can cause double-counting of deltas. This topic provides an overview of the types of retro and provides information to prevent double-counting of deltas.

There are two types of retro:

• Corrective retro realizes any deltas in the period in which they occur.

• Forwarding retro forwards deltas to the current period.

Although you might use forwarding retro in general, you can choose to have individual accumulators behave in a corrective fashion by selecting the Use Corrective check box on the Level page in the Accumulators component (GP_ACCUMULATOR). If you have selected this check box, then if a contributing member has adjustments brought into the current period, these adjustments will not be added to the accumulator.

The following example illustrates how double-counting could occur. In this example:

• The retro method is forwarding.

• Earning E1 contributes to accumulator E1_YTD.

• The value of E1 is 100.

The following table displays the results for the finalized January payroll:

After the January payroll is finalized, E1 is retroactively changed to 110. When you run the February payroll, Global Payroll also runs a retro revision of January. The following table displays the results of the February payroll:

The YTD amount in February should be 220, not 230. The 230 amount results from double-counting of the delta from January. To prevent this from happening, Global Payroll automatically passes not the V1R2 balance of 110 from January, but the V1R1 balance of 100. E1_YTD in February then equals the incoming balance of 100 plus 110 (current value of E1) plus 10 (adjustment to January amount), for the correct total of 220. In this case, the January E1_YTD value of 100 is the forwarded value, while the value of 110 is the calculated value. Both of these values are stored on the Accumulator results table, with the forwarded value stored in the field CALC_RSLT_VAL and the calculated value stored in the field CALC_VAL.

Since Global Payroll automatically handles the potential double count in forwarding retro, and since corrective retro does not pose the same sort of double-counting possibility, how could double-counting occur? The answer lies with segment accumulators. All other accumulators pass their ending balance along to the next segment processed to be used as a new starting balance. Segment accumulators exist only for the duration of the segment in which they are created. Therefore, the concept of a forwarding balance is not applicable to them; they only have a calculated value.

In the previous example, double-counting was prevented because the E1_YTD balance forwarded was the 100 taken from V1R1, not the calculated value of 110. If earning E1 also contributes to segment accumulator AC1_SEG, the substitution of the forwarded value for the calculated value would not take place, since forwarding is not applicable to segment accumulators. For AC1_SEG, both CALC_RSLT_VAL (forwarded value) and CALC_VAL (calculated value) equal 110. If the January value of 110 was added to AC1_SEG's February value of 120, the delta would be double-counted.

Therefore, if you pass a segment accumulator to General Ledger, you should define the segment accumulator as corrective. In the previous example, defining AC1_SEG as corrective would result in values of 110 for both January and February, with a combined correct total of 220.

Use the Countries page (GP_COUNTRY) to define retroactive processing for General Ledger.

Navigation:

Set Up HCM > Product Related > Global Payroll & Absence Mgmt > System Settings > Countries > Countries

See Countries Page.

Use Current Results + Adjustment for General Ledger

Most organizations that implement Global Payroll choose to use the default method to process the chartfields and element groupings that are posted to the General Ledger when retroactive processing occurs in a finalized payroll. These organizations only need to specify on the Countries page the default retro method, either forwarding or corrective, that is used by their organization, or that is most appropriate for their country extension of Global Payroll.

Other organizations prefer to post only V1R1 results to General Ledger. The To Process General Ledger check box is an additional option that addresses this business requirement, and permanently changes the way that the system handles General Ledger postings in relation to retroactive processing that has occurred in the payroll system.

The default setting for the To Process General Ledger check box is deselected. When you select it, you are telling the system not to reverse previous postings of chartfields and element grouping amounts to the General Ledger and to skip all topics and steps responsible for retro calculation (reversing) and instead send results from V1R1 and adjustments only. If you select the To Process General Ledger check box, the effect depends on the default retro method you use:

• If the Default Retroactive Method is Corrective, then selecting the To Process General Ledger check box does not affect the way that retro is processed for General Ledger.

• If the Default Retroactive Method is Forwarding, retroactivity changes as follows:

  • The system does not reverse prior chartfields and amounts associated with element groupings that have been mapped to General Ledger accounts.

  • The system does not post recalculated amounts to the General Ledger that result from retroactive processing in payroll. Instead, the payroll system sends current results (V1R1) plus adjustments to the General Ledger.

Note: If your retro method varies and you select the Use Current Results+Adjustment check box for General Ledger, you will see both retroactive methods, corrective and forwarding, in General Ledger results. Any forwarded element will include the amount of the delta or adjustment; the corrective method will reverse and correct previous entries.

Note: Do not enable either setting in the Use Current Results + Adjustment group box if you are satisfied with the way the system currently handles retroactive processing in relation to banking and GL. These settings are not backward compatible.

Note: Once you enable one or both of the Use Current Results + Adjustment settings, you cannot change them back to the default setting. The check boxes become read-only and remain so.

Note: The tables used by and modified in banking and GL are independent. Consequently, you can select the To Process Banking and the To Process General Ledger check boxes independently of one another.

See Process Definition Page.

Example: Selecting the Use Current Results+Adjustment Check Box to Process General Ledger When Forwarding is the Default Retro Method

In January a deduction with a payment of 100 is posted to GL account 210003, the account associated with ChartField Department 1. There is a change in payroll that triggers retroactive processing, and you realize that the employee whose payment was posted in January was really in Department 2, not Department 1. Deductions associated with Department 2 should be posted to GL account 210004.

This table summarizes the results that are sent to General Ledger when the Use Current Results+Adjustment check box is selected for General Ledger and forwarding is the default retro method:

Month	Version/Revision	Amount	Account #	Action
January	V1R1	100	210003	Resolution (last period)
February	V1R1	100 + 0	210004	Resolution (current period + adjustment)

In this example, the system does not send the reversal and reinstatement of chartfields and amounts associated with element groupings to General Ledger. It processes only the current period plus adjustment. (The adjustment in this case is 0 because the amount of the deduction does not change.) When using the To Process General Ledger check box, the system uses the current resolved chartfields. The system does not use the original chartfields. This may result in adjustments being posted to a different account.

Note: You must manually correct the January posting, as the amount is posted to the wrong account.

Regardless of the payroll system's retroactive mode—which can be corrective or forwarding—the GL calculations are always done in corrective mode. This means that all prior transactions for the retroactive period are reversed and new transactions are created for all entries from the recalculated results. This ensures that not only changes to amounts but also changes to chartfields and account assignments are reflected in the updated transactions. As a consequence, the numbers from the current period are always transferred to GL net of any forwarded adjustments.

This "corrective treatment" of the payroll results are not to be confused with the processing on the GL side. All transactions are posted based on the posting date given by the user when the GL process is kicked off and are not related to the original dates of the retroactive period, as those books are probably closed.

In January a deduction with a payment of 100 is posted to GL account 210003, the account associated with ChartField Department 1. There is a change in payroll that triggers retroactive processing, and you realize that the employee whose payment was posted in January was really in Department 2, not Department 1. Deductions associated with Department 2 should be posted to GL account 210004.

This table summarizes the results that are sent to the General Ledger . The system will reversal original posting and post the correct account for the January Run.

In case of segmentation mismatch, the system always uses current results plus adjustments and posts results to the last available segment.