One challenge that is often overlooked in connection with actual values, e.g. in target/actual comparisons, is retroactive accounting.
If, for example, a pay adjustment planned for January was inadvertently not carried out and made up for in April, the HR system (Payroll) recalculates this data in the past periods. In accounting, January to March are already closed, so the booking is made for the entire period in April.
This later becomes a problem in connection with target/actual comparisons, because actual values loaded from Payroll at the “for period” level no longer match the values in accounting. For one user, financial controlling in our example provides different data from January to April than payroll accounting. If the employee was transferred during the period, there will (probably) be postings in accounting that debit the employee’s current cost center and credit the previous cost center.
It is therefore necessary to decide for which date (HR “for period” or posting period) actual data should be supplied.
Almost all of our customers use the posting period to ensure comparability with financial controlling. But how do you deal with the fact that our example employee receives a very high salary in April from the point of view of financial controlling (due to 3 months of retroactive accounting) and only receives the correct salary from May onwards? This case is particularly unpleasant if we have just loaded actual values for April and not yet May.
A solution that is often used in practice is not to show the retroactive accounting, i.e. the back-paid values for January to March, in the employee’s remuneration (etc. up to social insurance), but only to show the values actually settled for April. This can be reliably “continued” into the future.
The retroactive accounting values are posted to the cost center or in separate amounts for the employee in April, so that the total results in the correct value without showing an absurdly high remuneration (etc.) for the employee in April.
Theoretically, you could also correct the remuneration (etc.) from January, i.e. load the data into the “for period” of the accounting system – but this would then no longer match the accounting. In addition, you would then have to load an indefinite period of time in the past, depending on the date on which retroactive accounting falls – which may well be in the previous financial year.
Conclusion
Retroactive accounting is always a challenge that needs to be overcome. They are directly related to the decision as to whether you want to output results in HR controlling analogous to financial controlling or analogous to payroll accounting.
Would you like to find out more about this topic or HR controlling in general? Learn more here: https://www.software4you.com/en/solution/
