Changing one transaction may trigger related transactions
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.
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 taxable benefits or even employee benefit deductions 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, 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 five per cent of gross wages to a registered retirement savings plan (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 Canada Pension Plan (CPP) or Quebec Pension Plan (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.
Payroll systems that rely on a limited set of “buckets” or accumulators may have trouble recognizing the same payroll transaction on either an accrual or cash basis. Modern relational database systems 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 varies.
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:
• If vacation time is taken, vacation pay 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 pre-defined 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 20 years’ experience in all aspects of the industry. He can be reached at [email protected], (905) 401-4052 or visit www.alanrmcewen.com for more information.
