In shift-based environments, planning and reality often don’t match.
Employees swap shifts, cover for colleagues, or work on short notice. While this keeps operations running, it creates complexity in time valuation.
Especially when it comes to premium calculation.
Let’s look at a common scenario:
- An employee is assigned a rotating work schedule (early, late, night shift)
- On a given day, they are planned for an early shift
- Due to a short-notice substitution, they work a night shift instead
Now the key question is:
How do you calculate the premium correctly?
- Based on the actual worked shift?
- Or based on the original planned shift?
In many cases, you actually need both perspectives.
In existing configurations, you had access to Scheduled Working Time based on Temporary Time Information (TTI) → representing the actual shift after the change
But you were missing easy access to the original scheduled working time from the work schedule
This often led to:
- Complex workarounds
- Hard-to-maintain valuation logic
- Limited flexibility for advanced scenarios
With the 1H 2026 release, SAP SuccessFactors Time Tracking introduces a simple but powerful enhancement:
Source Behavior in Time Type Groups
You can now decide where scheduled time should come from:
Default Behavior → reflects the actual shift (TTI in case of changes)
Original Work Schedule → reflects the planned shift according to the assigned Work Schedule, regardless of changes
To illustrate the concept, let’s walk through a simplified example.
⚠️Important: This example is intentionally simplified to explain the principle.
Your configuration may differ depending on your business requirements, collective agreements, and existing Time Recording Profile.
Introduction
According to the company policy, the following time-dependent premiums need to be calculated:
- 02:00 PM – 08:00 PM: 10%
- 08:00 PM – 12:00 AM and 04:00 AM – 06:00 AM: 25%
- 12:00 AM – 04:00 AM: 35%
These premiums should be calculated for:
- The recorded working time in the actually worked shift, and
- The planned working time of the originally scheduled shift
Premiums for Recorded Working Time (Actual Shift)
Even though the configuration for time-dependent premiums based on recorded working time is typically well understood, the following visualization shows a simplified example setup for this scenario.
Premiums for the Originally Planned Shift
This is where it becomes more interesting—and where the new enhancement comes into play.
For the originally planned shift, there is no recorded working time, because the employee worked a different shift.
However, we can still calculate what the premiums would have been if the employee had worked as originally planned.
This is possible by using the Scheduled Working Time of the original work schedule.
With the new Source Behavior in Time Type Groups, the configuration becomes straightforward, as illustrated below:
⚠️Note: In the Time Recording Profile visualization, the Work Schedule Source is currently not displayed. Both the Scheduled Working Time and Breaks used here are configured with “Original”.
Configuration “In a Nutshell”
Let’s take a closer look at the core idea behind this configuration.
To calculate premiums for the originally planned shift, we first need to determine the net planned working time.
- Similar to the calculation for recorded working time, we need to deduct breaks. In this case, however, breaks are subtracted from the scheduled working time of the original shift, not from recorded time
- The breaks must also be taken from the Day Model of the originally planned shift
Once we have the net planned working time, we can apply the same time filters to determine the premiums that would have been generated.
Avoiding Incorrect Premium Calculations
Premiums for the planned shift are only relevant if the employee actually worked on that day. Otherwise, premiums could be calculated even if the employee was absent.
To prevent this:
- Potential premiums are first calculated in intermediate Time Type Groups (e.g., TEMP1…)
- These results are only transferred to the final premium Time Type Groups if recorded working time exists on that day
Possible Enhancement
As a further improvement, you could extend the logic to check whether the actual worked shift differs from the originally planned shift.
This ensures that premiums for the originally planned shift are only calculated when a shift change actually takes place.
Results
Let’s look at the result of this configuration.
We can see that the employee was originally scheduled to work a night shift on May 4, 2026.
For this day, the following Temporary Time Information (TTI) was created:
This means the employee switched from a night shift to a late shift.
During the late shift, the employee recorded working time that corresponds to the scheduled working time.
Based on the defined policy and considering unpaid breaks, we would expect the following premiums for that day.
The expected results are illustrated below:
As shown in the final result:
The time valuation correctly calculates:
- The premiums for the actual worked shift, and
- The reference premiums for the originally planned shift
Both are available in the expected Time Type Groups.
The enhancement described in this blog post can also play an important role in overtime and undertime calculation, especially in scenarios involving workforce scheduling.
This becomes particularly relevant when changes in shift planning turn non-working days into working days, or vice versa, and when no Working Time Account is used.
Consider the following case: An employee is scheduled to have a day off but is later assigned to work a shift on that day.
From a business perspective, the entire worked time should be treated as overtime.
However, if the calculation is based on Recorded Working Time – Planned Working Time (from TTI) the Temporary Time Information introduces a planned working time for that day, resulting in reduced or even no overtime.
By instead using Scheduled Working Time from the originally planned work schedule the system correctly identifies that the day was originally a non-working day, and therefore the full recorded working time is correctly evaluated as overtime.
This example highlights how the new flexibility helps ensure accurate results in edge cases and avoids hidden inconsistencies caused by relying solely on updated shift data.
With this approach, you can clearly separate:
Actual worked shift
- Basis for premium calculation
- Reflects what really happened
Originally planned shift
- Basis for reference and validation logic
- Reflects what should have happened originally
This enhancement directly addresses a well-known customer challenge:
- No more complex workarounds to simulate planned vs. actual comparisons
- Cleaner and more transparent time valuation logic
- Increased flexibility for advanced scenarios
At the same time, it opens the door for new use cases:
- Calculations based on shift deviations
- Overtime scenarios on non-working days
With the new Source Behavior, you can finally work with planned and actual shift data side by side
This allows you to:
- Simplify existing configurations
- Replace workaround logic
- Build more flexible and robust time valuation rules
We continue to enhance time valuation flexibility.
⚠️Note: Please note that all planned innovations are subject to change.
Planned for 2H 2026
- Access to Shift Classification of the original planned shift within the Time Records Filter, enabling even more precise valuation logic (also for duration recorders).
Planned beyond 2H 2026
Planned extension of Point-to-Point (P2P) replication to SAP Payroll: Premium replication is already supported today. Future enhancements will provide both planned-shift-based and actual-shift-based premiums to Payroll, enabling it to decide which premium should be paid in scenarios such as shift changes.
