We’ve covered the typical decision points for the new UK holiday pay and the respective technical options in SAP Payroll so far. Now we use a few „special cases“. On the agenda: seasonal peaks, annual leave woven into the work schedule without using absences, overtime payments not assigned to a particular day, and using in-period values („as paid“) rather than for-period values („as earned“) to calculate the averages for top-ups.
1) Seasonal Peaks in Overtime
If your business is seasonal, chances are there will be seasonal peaks in overtime payments too. This would make the holiday pay uplift calculation unfair if it was based on just 3 months. As far as we understand, you would be allowed to base the uplift on the last 12 months to even that out, though as always you should get legal advice for all interpretations of court rulings or legislation.
From an SAP Payroll point of view, it doesn’t really make a difference. The only point to observe is: you need to have the respective data available in your payroll results 12 months back. If you use the standard function AVERA (one of the solutions suggested in part 2 of this series), this might require quite a long retroactive run
2) Annual Leave Hidden in the Work Schedule
Some organisations, especially when they have complicated shift patterns and aim at stable teams per shift, don’t have most of their annual leave in an entitlement flexible to use. Instead, they incorporate some or all of the leave into the shift patterns. E.g., if you’d usually expect 240 working days in a year in a work schedule and employees have 25 days annual leave, then there is no leave account granted, but the working days in the shift pattern are reduced to 215.
In this case it is difficult for the system to establish which are the 25 days off in the work schedule representing the annual leave quota. You might be able to use the daily work schedule class, but than you’d still need to make sure things go right when an unplanned absence, e.g. sickness, occur on such a day. If you use a custom function to calculate holiday pay in SAP Payroll, you could establish an algorithm to distribute the days getting an uplift evenly across the year. Standard configuration is probably not the best way to deal with this case.
3) Overtime Payments not Assigned to a Date
If an overtime payment is assigned to hours worked on one particular day, it’s pretty clear whether they belong to the period considered or not. But quite often all or some of the overtime goes into a bank account / flextime account and then can be paid off at a different time, e.g.:
- all hours left in flextime at year end are paid off on 31st December
- the employee can choose to have them paid at any time
- whatever is above 30 hours at the end of any month is paid off
Whilst the last case still has a payment originating in the month the hours have been worked in, the other two can lead to payments originating in a month that no overtime has been worked in at all.
This is a business/legal question much more than a technical question for SAP Payroll configuration. It would be easy to pick up all those payments in the month they are paid, but is that right? In the first case that would mean leave taken at the start of the year has a potentially very high valuation for holiday pay and in the second case the employees could easily pump up their holiday pay by requesting pay off the month before their vacation.
As the legal texts talk about „mandatory“ overtime, it may be argued that hours in a flextime account have been offered to be taken as extra time off per definition and therefore don’t need to be considered at all for holiday pay. In any case: a point to discuss with the legal expert. Unfortunately, our experience suggests that these points are not touched by legal advisors pro-actively. They tend to make the legal side very complex, but completely neglect the complexity and variety of process. It actually does help to include your SAP Payroll expert in the discussion early on, as a well structured IT view tends to make sure all cases are covered and is practical rather than philosphical.
4) Using in-Period Values Rather than for-Period Values
So far we have assumed that the calculation of an average, if based say on 3 months, uses the amounts for overtime worked in these three months – no matter when they have been paid. That is what we refer to as „for-period“ values, sometimes also labelled „as-earned“. This means that:
- Paying overtime late, e.g. because of delayed approval, doesn’t effect the eventual outcome
- Retroactive changes to the overtime payment for the 3 relevant months also leads to a change in the holiday pay. At first sight one might not want that, but if an employee’s overtime payment is been changed retroactively, maybe even because he or she complained about an error, they would expect their holiday pay to change accordingly.
We’ve seen at least one SAP Payroll customer using in-period values for this calculation, also referred to as „as-paid“. This means that all overtime hours paid in the 3 relevant months are considered to calculate holiday pay – no matter when the corresponding overtime hours were actually worked. This leads to this kind of effects:
- If an employee works 30 overtime hours in the 3 relevant months before her holiday, but they are all only paid in or after the holiday month (and assuming no other overtime is paid in that 3-months period), no holiday pay uplift is calculated. For comparison: using for-period values would also not calculate the uplift initially if payment happens after the holiday month – however: the employee would receive the uplift retroactively as soon as the overtime is finally approved and paid.
- On the other side: if the employee hasn’t worked any overtime in the 3 months period, but overtime from earlier months is paid in that period, than that overtime is used to calculate an uplift.
- The 2 points above also show that this method leaves opportunities for manipulation – or allegations of manipulation. An employer could reduce the holiday pay of an employee by delaying approval of overtime payments. An employee could delay requests for overtime payment of older month to get them paid 3 months or less before his summer holiday.
- In an extreme, but not that unlikely scenario, the in-period method of calculation could lead to negative holiday pay uplifts. If an employee had 200 pounds worth of overtime in, say January, and that overtime is canceled in May, the in-period value for overtime in May is -200 pounds. If that’s the only overtime value between March and May, the average for the uplift in June would be a negative number. Sure you don’t want employees to be paid less then the normal salary when they are on holiday, so you’d need to make sure the average never goes below zero.
You may have guessed from the comments above that we are not really fans of this calculation method, but we can’t comment on whether or not it is legally the right choice for a particular context. From a process point of view it is definitely difficult to explain as the holiday pay is no longer connected to the overtime worked in the last 3 months, but on the payments that happen to have been paid more or less randomly in that period. From a technical SAP Payroll point of view: SAP standard configuration definitely is not an option for this variant, you’ll need to program a custom operation.
So, these 4 examples should get the point across that you may hit some very interesting questions when implementing the new UK holiday pay. There are quite a few ways to calculate it, and it seems different customers have been advised in different ways as to what is the „right“ way of doing it. Many of them probably are. What you really shouldn’t do is:
- get a detailed calculation process carved in stone without checking with your SAP Payroll expert first. Quite often rules defined are not only difficult to implement, but also inconsistent or just plainly mathematically wrong.
- go with the word of the ruling or a legal text without asking whether the easier methods would do
- wait with implementation until every detail is clear and 100% sure. Changes are almost certain, but getting a reasonable process in place soon will make it far less likely for your employees to feel shortchanged and possibly take you to court.
