I wanted to follow up on the blog post from Paige Menge on July 16: Effective Date vs. Action Date, where she discusses the use of an “Action Date” (when something happened, such as an employee termination), vs. an “Effective Date” (when it is actually entered into a system or database). Paige states, quite correctly, that using an effective date to prepare reports and analysis will lead to incorrect information and, potentially, conclusions drawn from it.
While this should be intuitively obvious to most (if an employee terminates on June 30, it should be included in June’s turnover rate, even if it gets entered into the system on July 3), why do organizations continue to wrestle with this problem, and why do many continue to use effective dates in their reports and analyses instead of action dates? Part of the answer lies, I think, in the fact that organizations typically want their data to have three key characteristics, but it’s only possible to have two at any one time:
They want the data to be accurate: As mentioned earlier, they want a June transaction to be included in June numbers, even if it is not entered until July.
They want to get their data quickly: For example, many organizations push HR to publish an audited turnover report within the first few days of the following month. This is particularly true of organizations which manage their headcount very closely.
They don’t want the data to change: For many senior leaders, once they see an HR (or financial) report, it is more or less set in stone, and any subsequent changes to it will lead them to question its overall accuracy. Even small changes- “Earlier you said turnover was 9.2%, this says it’s 9.3%”, can trigger this reaction.
What then is a company to do? If it quickly reports numbers that are accurate (at the time), it may need to revise their reports later as new backdated data comes in. If it reports numbers that are accurate and that don’t change, it will probably have to wait until later in the month to report results, once all the transactions from the prior period have come in. If it reports data quickly and refuses to update it, then the data will be wrong as it will exclude the handful of transactions that come in after the books have closed for the period.
In a lot of cases I think this is a matter of communicating these choices to management and getting their sense for how to prioritize. Once they see that they cannot, in fact “have it all”, it’s usually fairly easy to get down to what an organization values most. There’s a similar conundrum for project work: of the three desirable outcomes- fast, cheap and good, you can usually only get two. A decision must be made by the organization as to which two are the most important.
The best answer, as Paige mentioned, is to have a firm cutoff date at the end of a reporting period by which time all transactions are captured and entered. For many organizations this is simply not possible however, and the next best solution must be found. There is no one right answer in this case, though for internal communications I’ve found that the issuance of “preliminary” HR reports early in the month followed up by slightly modified “final” reports later works well for many organizations. This assumes that there is general understanding that the preliminary data may change slightly (“oh, so that’s why turnover is now reflected as 9.3%”) and that this won’t cause the broader validity of the data to be called into question.
This approach works less well for data to be communicated externally, as it is difficult to explain the changes in the data between preliminary and final to a broader audience. In this case, it can be instructive to see how Finance and Accounting handles the problem, as they face the exact same challenges in reporting their data. A consistent approach between Finance and HR will serve all parties well in this case.
Tags: action date, Effective Dating, HR Analytics, HR data, Monthy Cutoff, strategic hr management
“Effective Date” is the change goes into effect. “Action Date” is the change was entered into the system. I think the confusion is caused more by the name of the field “Action Date” than anything else. Most people don’t seem to understand it is the date the change was made to the employee’s HR data.