Say that executives want to track head count over time, and in order to understand how head count is changing they want to know the number of new hires and terminations each month. So, maybe this month your report looks like this:
| Date | Head Count | New Hires | Terminations |
|---|---|---|---|
| Jan 2019 | 1100 | 10 | -9 |
| Feb 2019 | 1098 | 0 | -2 |
| Mar 2019 | 1102 | 4 | 0 |
| Apr 2019 | 1106 | 6 | -2 |
| May 2019 | 1103 | 1 | -4 |
Then the next month your report might look like this:
| Date | Head Count | New Hires | Terminations |
|---|---|---|---|
| Jan 2019 | 1100 | 10 | -9 |
| Feb 2019 | 1098 | 0 | -2 |
| Mar 2019 | 1102 | 4 | 0 |
| Apr 2019 | 1106 | 6 | -2 |
| May 2019 | 1102 | 2 | -6 |
| Jun 2019 | 1108 | 2 | 0 |
So what happened? So at the end of May you reported May closed out with 1 New Hire and 4 Terminations, but when you reported at the end of Jun, May’s report numbers changed!? Now you are reporting 2 new hires and 6 terminations. This is where the executive team begins to doubt your reporting. Were you wrong when you originally reported May or are you wrong now when you restated the numbers in Jun?
Well the answer is neither. You were right in both times which makes all of this very confusing. How is that possible? This situation comes up in HR systems because your HCM system may lag in being updated with data, especially when people terminate or hired close to the end of the month. All it takes is a long weekend or someone on vacation and your HCM system misses the end of a month boundary, and this situation happens. When those reports slip across a month boundary we can encounter situations like this.
When a termination or new hire is entered into the system for a prior month it’s a retro-hire or retro-termination. For example, if I terminate someone by setting their effective termination date to May 29, 2019, but I perform that action on Jun 3rd, 2019 that will be modeled as a retro-term. The same thing applies to retro-hires where I enter a change on June 2nd, 2019 with an the effective hire date on May 30, 2019. That change will result in a retro-hire.
These changes made to the past create confusion when comparing reports from the past. So to eliminate the confusion about manipulating the past reto-hires and reto-terms are modeled separately. Therefore, when I generate the report at the end of June I’ll see this:
| Date | Head Count | New Hires | Retro Hires | Terminations | Retro Terms |
|---|---|---|---|---|---|
| Jan 2019 | 1100 | 10 | 0 | -9 | 0 |
| Feb 2019 | 1098 | 0 | 0 | -2 | 0 |
| Mar 2019 | 1102 | 4 | 0 | 0 | 0 |
| Apr 2019 | 1106 | 5 | 0 | -2 | 0 |
| May 2019 | 1102 | 1 | 1 | -4 | -2 |
| Jun 2019 | 1108 | 2 | 0 | 0 | 0 |
Now when reports change in the future only the retro-hires or retro-terms columns will change. The termination and new hire columns are locked in history which makes the numbers stable. Retro-hire/terms help the consumer understand these historical changes more easily by breaking them out. However, they also benefit you by saving your afternoon from having to dig into the row level details to figure out how new records affected the numbers.