Retroactive payroll processing can be one of the toughest tasks faced by any payroll system. Yet, for many employers, the ability to process retroactive pay adjustments is a fundamental requirement. This article explains some of the basic needs before a payroll system can be said to properly handle retro processing.

Retroactive pay adjustments mean changes in employee pay, made after the pay period for which those changes are effective. Retroactive pay adjustments usually mean increases in gross pay, but sometimes it’s taxable benefits or even employee benefit deductions that are changed on a retroactive basis.

There are several things that make retro processing such a complex payroll task.

First, retro processing creates a distinction between payroll values measured on a cash basis, versus those measured on an accrual basis. Another way of saying this is that, for some purposes, retro results may be applied to the initial, historical pay period itself, while, for other purposes, the same retro results may be recognized in the current pay period in which retroactive processing takes place.

Second, retroactive changes in one transaction may trigger changes in other, related payroll transactions. For example, employees may contribute 5% of gross wages to an RRSP. If gross wages are retroactively increased, RRSP contributions for the retro period may also have to be adjusted. In other words, a retroactive change in one transaction may have cascading effects elsewhere in payroll. This becomes more complex still if the related transactions are subject to annual caps or limits, such as on CPP or QPP pensionable earnings.

Third, retroactive changes are not always an increase in wages, but may be reductions or decreases. For example, an employee’s position may be changed on a retroactive basis. If there are different earnings or deductions between the two, the transactions in the old position will have to be reduced and those in the new position, increased. So the mathematical sign of any retroactive change may be negative as well as positive.

This impacts how payroll values must be stored, for later use both in payroll calculations and in reporting. For example, if the amount of a taxable benefit is retroactively reduced, that reduction impacts source deductions very differently than a retroactive increase in wages. If wages in one tax year are retroactively increased in a following tax year, the retroactive increase is taxed using the tax rates and logic that apply to the following year. By contrast, if, after filing the T4, an employer has to retroactively reduce an employee’s standby charge, this affects the prior tax year, the one for which the T4 was issued. This means the prior year T4 will have to be amended.

To properly handle such retroactive implications, a payroll system has to be able to recognize when a payroll transaction applies to the initial pay period versus when it applies to the pay period in which retro processing takes place. The most common technique is to mark each payroll transaction, or set of results, with two separate pay periods: the pay period earned on an accrual basis and the pay period processed on a cash basis. Payroll systems sometimes use a set of to and from date pairs for this purpose, rather than complete pay periods. This has the added benefit of facilitating the proration of mid-period payroll changes.

Payroll systems that rely on a limited set of “buckets” or accumulators often have trouble with recognizing the same payroll transaction on either an accrual or cash basis. Modern relational database systems now make it possible to store just the raw history of each payroll transaction. Where totals are needed, they are generated on the fly from this raw data. Decades ago, before fast, robust relational databases became commercially available, the only realistic design strategy was to store payroll processing results in a limited set of “buckets” or accumulators. For example, a payroll system would allocate a single accumulator to store T4 box 14 earnings. When that value was needed at year-end, it would be read from the bucket assigned for that purpose. While modern database technology no longer requires this approach, many payroll systems still rely on such accumulators for key payroll values such as YTD CPP contributions.

The problem with this “bucket” approach is that for one purpose a single payroll transaction may have to be recognized for its historical pay period, while for other purposes the same transaction may have to be recognized on a cash basis, when processed. The use of “buckets” to report payroll history becomes increasingly difficult when the pay period that applies might vary, based on circumstances.

The best example of this difficulty is the allocation of EI insurable earnings for vacation pay. There are three different rules on how vacation pay may be allocated for EI reporting purposes:

• If vacation time is taken, vacation pay, whenever paid, is allocated to the time taken;
• If vacation pay is paid because of a different type of leave, a lay-off or the end of employment, vacation pay is allocated proportionately to insurable weeks in the last pay period in which regular wages were paid;
• Otherwise, vacation pay is allocated to the current pay period. This means:
  • if paid on a regular pay day, proportionately to the insurable weeks for that pay period; or
  • otherwise, proportionately to the insurable weeks between the first and last pay period days between which the payment falls .

A payroll system that depends on transaction values being loaded into a single predefined reporting “bucket”, at the time of processing, will not likely have the flexibility to cope with the vacation pay requirements described above, nor with the requirements of retroactive payroll processing.

Alan McEwen is a payroll consultant and freelance writer with over 20 years’ experience in all aspects of the industry. He can be reached at armcewen@cogeco.ca, (905) 401-4052 or visit www.alanrmcewen.com for more information. This article was first published on Canadian HR Reporter and Canadian Payroll Reporter on January 15, 2013.