Double-Counting of Deltas

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:

Calendar	Revision	E1	E1_YTD
January	V1R1	100	100

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:

Calendar	Revision	E1	E1_YTD
January	V1R2	110	110 Delta of 10 is forwarded.
February	V1R1	120	230 Adjustment of 10 is brought in.

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.

Note:

The passing of the first revision accumulator balance only occurs if the retro method defined for the accumulator is forwarding. If the retro method for the accumulator is corrective, the forwarded value is equal to the calculated value. Adjustments are not brought into the current period, so no double-counting occurs.

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.