Once upon a time, the concept of retroactive payroll processing was invented to handle the all too often situation of a personnel action (that’s what they were called when I was young) that was presented to “the system” after the date on which is should have taken effect. Without a retroactive processing capability in payroll, someone would hand calculate the delta for every element of gross pay and every deduction between what had been calculated — and this could involve many pay periods — and what should have been calculated. They would then determine how to handle that delta in terms of making specific changes to the current payroll calculations, adding a little to gross pay here and/or taking a little away from specific deductions there. Annoying yes, but an entirely doable manual process when the odd personnel action was late.
But what about all that hand calculating when a LABOR AGREEMENT was finally signed six months after the end date of the previous agreement and with all provisions made retroactive to that end date? Or when it was discovered, six months into the year, that the health care plan deduction amounts table was in error? Or when, at year-end, it was discovered that the FICA calculation had run amuck? As the workload grew from all this hand calculating and manual adjusting, a clever programmer, whose name has been lost in the mists of time, saw the possibility of creating a payroll application which could do much of this in an automated way. With a little effective dating here, and a little re-entrant code there, the first, modestly capable, retroactive processing payroll — one of my preferred behaviors — was born.
But, as with so many great inventions, it became obvious very quickly that these early efforts could only handle some very specific and limited retroactive processing scenarios (or Use Cases). What if there were intervening rule changes between the date on which the delayed personnel action should have been processed and when it was actually processed? What if there were ripple effects that weren’t just about payroll calculations, to include the domino effects when succession plans are executed? What if there wasn’t just one error in the health care plan deduction amounts table but an error there and in the corresponding eligibility criteria so that employees were ending up in the wrong plans as well as having the wrong amounts deducted for those plans? To make further progress in retroactive processing, to decide how far to go/at what cost/with what business case, we needed some way of organizing the many possible scenarios.
With too many different flavors of retroactive processing to count, let alone to provide written scenarios here, this taxonomy, which I’ve been using for nearly twenty years, provides a framework for the discussion — and for developing scenarios for those flavors that are relevant to your business. Retroactive processing may be needed to accommodate:
- A single late event with no intervening rules changes or ripple affects — with and without $ affects;
- A single late event with no intervening rules changes but with a ripple affect — with and without $ affects;
- A single late event with intervening rules changes but no ripple affects — with and without $ affects;
- A single late event with intervening rules changes and ripple affects — with and without $ affects; and
- A group of late events under thesel eight conditions.
- A single incorrect event with no intervening rules changes or ripple affects — with and without $ affects;
- A single incorrect event with no intervening rules changes but with a ripple affect — with and without $ affects;
- A single incorrect event with intervening rules changes but no ripple affects — with and without $ affects;
- A single incorrect event with intervening rules changes and ripple affects — with and without $ affects; and
- A group of incorrect events under these eight conditions.
- A single late rules change with no intervening rules changes or ripple affects — with and without $ affects;
- A single late rules change with no intervening rules changes but with a ripple affect — with and without $ affects;
- A single late rules change with intervening rules changes but no ripple affects — with and without $ affects;
- A single late rules change with intervening rules changes and ripple affects — with and without $ affects; and
- A group of late rules changes under these eight conditions.
- A single incorrect rules change with no intervening rules changes or ripple affects — with and without $ affects;
- A single incorrect rules change with no intervening rules changes but with a ripple affect — with and without $ affects;
- A single incorrect rules change with an intervening rules change but no ripple affects — with and without $ affects;
- A single incorrect rules change with intervening rules changes and ripple affects — with and without $ affects; and
- A group of incorrect rules changes under these eight conditions.
This is another one of those situations where no one in their right mind would attempt to automate every possible scenario because the cost of doing so would far outweigh the benefits of being able to handle something that rarely happens or whose cost to correct manually is quite reasonable. But this taxomony should be translated by end-users into “killer” scenarios that test any HCM software of interest for its retroactive processing capabilities — far beyond payroll of course — as they would impact the real world needs of that end-user. And HCM software vendors will want to ensure that their products do a great job of handling those retroactive processing scenarios that are appropriate to their scope and target markets.
Now how many verb tenses will you need to write those scenarios? And what scenarios have you encountered that don’t have a home in my taxonomy? There’s a bottle of Tres Generaciones waiting for you if you’re able to propose an HRM scenario for which the taxonomy doesn’t provide a home.