Using Retroactive Calculations in Banking

In the banking process, making sure that the appropriate source bank funds transactions and the right recipients or net pay accounts are debited and credited can require retroactive calculations to correct previous calculations. To determine how to handle transactions, banking must recognize retro processing and the method used.

Define your payroll retroactivity defaults on the Countries page (Set Up HCM, Product Related, Global Payroll & Absence Mgmt, System Settings, Countries). This page is discussed in other topics in this product documentation.

See Countries Page, Setting Up Retroactive Processing.

If you select Corrective as the Default Retro Method on the Countries page, the system completes the following steps when retroactive processing occurs:

1. Recalculates the elements of the pay run that are defined to be recalculated during retro.

2. Replaces previous calculations with the recalculated values for the elements of the pay run.

3. Updates balance and segment accumulators in the recalculated period.

4. Computes retro deltas and stores them in the recalculated period.

5. Computes the retro adjustment for elements of the pay run that are defined as forwarding element overrides (on the Retro Process Overrides page).

6. Determines if any differences exist between the net pay from the prior calculation and the recalculation.

7. Banking processes the differences. Reverses all segments for net pay entries from the prior calculation where the net pay isn't being forwarded.

   Inserts new segment net pay entries from the recalculation where the net pay isn't being forwarded.

8. Distributes all net payments according to the net distribution sets matching the run type, the EmplID/Empl Record (employee ID and employee record), and period ID combination.

   Deletes all entries where the sum is zero.

If you select Forwarding as the Default Retro Method on the Countries page, the system completes the following steps when retroactive processing occurs:

1. The system recalculates the elements of the pay run that are defined to be recalculated during retro.

2. Recalculated values for the elements are used to compute the retro deltas for the recalculated period, but do not replace the previous calculations.

3. The system updates segment accumulators only. (Although you can define balance accumulators to behave in a corrective manner at the accumulator definition level and on the Earnings/Deductions Accumulators pages even when the retro method is forwarding).

4. The system computes retro deltas and stores them in the recalculated period.

5. The system computes the retro adjustment for elements of the pay run that are defined to be forwarded (on the Retro Process Overrides page).

6. The banking process picks up only the net pay from the current period calculation because differences from the prior recalculated periods are included in the current period.

The deduction process completes the following, regardless of retro method:

1. Reverse deductions from all prior retro period calculations in the calendar group.

2. Reinstate reversed deductions where the payroll method is forwarding, because the purpose is to reassign the correct recipient.

3. Insert the new transactions for any recalculated deductions where the method is corrective.

   This involves two steps, first for general recipients and then for individual recipients.

4. Remove entries resulting in 0 that have the same recipient ID.

This is what happens when the "To Process Banking" option is not selected.

This example illustrates the interaction between source bank, recipient, and payee accounts for net pay. February (February 1, 2004 − February 28, 2004) represents the current period, with retro processing going back to January (January 1, 2004 − January 31, 2004).

• Company ABC uses Source Bank 123. Company DEF uses Source Bank 789.

• Payee changes from Company ABC to Company DEF, effective February 1.

• Company ABC changes from Source Bank 123 to Source Bank 456, effective February 15.

• Earning 1 rate changes from 100 to 150, effective January 1.

• Deduction 1 rate changes from 20 to 25, effective January 1; no recipient change.

• Deduction 1 recipient changes from Recipient X to Recipient Y, effective February 1.

• Deduction 2 recipient changes from Recipient A to Recipient B, effective January 1; no rate change.

• Payee account distribution changes from Account 1 to Account 2, effective February 1.

Explanation of January recalculation (V2R1):

• Deduction 1

  The difference between V1R1 and V2R1 results in 5.

  The recipient is determined based on where the payee was when the deduction was first calculated (January V1R1). In this case, because there was no change in recipient for Deduction 1, the difference of 5 goes to Recipient X, funded by Source Bank 456.

• Deduction 2

  No difference exists.

  There's a recipient change retroactive to January. From Recipient A, 15 is reversed and inserted to Recipient B. Each transaction is "charged" to Source Bank 456.

• Net Pay

  The difference between V1R1 and V2R1 results in 50.

  The payee account distribution is determined based on the pay date of the current calendar (February). The difference, 50, goes to Payee Account 2 and is funded by Source Bank 456.

This example illustrates that net pay and deductions are allocated to Company (payment keys) and recipients are based on pay period, whereas source bank and payee accounts are selected based on when transactions are created.

Most organizations that implement Global Payroll choose the default method that the application uses to process banking in relation to retro. These organizations need only specify, on the Countries page, the retro method, either forwarding or corrective, that is used by their organization or is most appropriate for their country extension of Global Payroll.

Other organizations prefer to post only V1R1 results to banking. The To Process Banking check box on the Countries page is an additional option that addresses this business requirement, and permanently changes the way that the system handles banking in relation to retro. The default setting for the To Process Banking check box is deselected. When you select it, you are telling the system not to reverse old payments in banking and to skip all sections and steps responsible for retro calculation (reversing) and instead implement results from V1R1 and adjustments only.

If you select the To Process Banking check box on the Countries page, the effect is different depending on the default retroactive method:

• If the Default Retroactive Method is Corrective, the enhancement does not change the behavior of corrective retro in banking.

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

  • The system does not reverse prior amounts or post recalculated amounts during retroactive processing. Instead, the system implements current results (V1R1) plus adjustments in banking.

  • You may have to manually correct any discrepancies you identify in banking payments because retroactive changes to recipients or accounts cannot be reflected by the current results plus adjustment method.

  • In case of segmentation mismatch, the system always uses current results plus adjustments and posts results to the last available segment, regardless of the default retro method defined on the Countries page, or the check boxes you select in the Use Current Results + Adjustment group box.

    Segmentation mismatch occurs when a segmented period is recalculated retroactively, and the segmentation dates of the original calculation don't coincide with those of the recalculation.

In this example a deduction with a payment of 100 is made to Recipient 1 in January. In February the recipient is changed to Recipient 2, effectively dated in January, thus triggering retroactive processing. When the To Process Bankingcheck box is selected for banking, and forwarding is the default retro method, the system posts this recipient and amount information to banking results:

In this example, the system does not process the reversal and reinstatement. It processes only the current period plus adjustment. (The adjustment in this case is 0 because the amount of the deduction does not change.)