Calculating overtime is already partly automated today, and this is continuing to change. The task breaks down into three parts. Adding up registered hours and applying fixed collective labour agreement thresholds to those hours is work a system can already do today, provided the rules are correctly built in. Assessing borderline cases -- an employee who just crosses a threshold due to a correction made afterwards, or an allowance that only applies to a specific combination of day and time -- is work where a human approves or rejects with reasoning. And determining what a collective labour agreement actually means on an unclear point remains human work: that is interpretation, not calculation.
This three-way split is not something for the future -- it already runs through the teams doing this work today. At a company with a clear, unambiguous collective labour agreement and clean time registration, the largest part of the calculation already sits with a system. At a company with multiple collective labour agreements, many exceptions, or time registration that is often corrected after the fact, the weight still lies with the HR employee or payroll administrator who checks by hand.
The calculation itself is highly structured: hours in, collective labour agreement rule applied, allowance or overtime out. It requires no customer contact, no physical action and no creativity -- it is calculation work based on fixed rules. That is why the task scores on the side favourable to automation on those axes. A system that knows which threshold belongs to which collective labour agreement and which hours have been registered can produce the overview without requiring case-by-case interpretation.
An example: an employee works two hours longer on a Wednesday evening. The system sees the registered hours, recognises that the collective labour agreement prescribes an allowance of a fixed percentage above a certain threshold, and converts this into a line on the overview for payroll processing. No assessment, no exception -- simply application.
The reason this task is not simply handed over to a system lies in two other axes. Compliance scores low: collective labour agreement rules change, differ by sector and by company, and an incorrectly applied rule is a compliance error, not a detail. The cost of errors also scores low: an allowance calculated incorrectly, or a missed allowance, directly affects an employee's pay and must be corrected later. Those two axes weigh more heavily than the structured nature of the calculation step itself, and that is why the answer to whether AI can take this over is: partly, and with conditions.
The scope for judgment is also low, which at first glance seems favourable -- less room for interpretation means less risk of a wrong judgment call. But low scope for judgment combined with a low cost of errors mainly means there is little margin for letting an error pass unnoticed. An incorrectly built-in rule works its way structurally through every overview the system produces afterwards.
The technology that can handle this task today is RPA: a system that applies fixed rules to fixed data. That works as long as two preconditions are met. The collective labour agreement rules must be current and correctly built in, including changes that may take effect midway through a year. And there must be a sample check on the outcomes, so that deviations are noticed before they reach payroll processing. Without those two conditions, this is not automation of the task but a risk shifted from the calculation to the check that follows it.
At a company with a single collective labour agreement, stable time registration and few exceptions, the largest part of the calculation step can be left to a system, with a light sample check as a safety net. At a company with multiple collective labour agreements, shift work, or time registration that is regularly adjusted after the fact, a larger part remains with a human who assesses the outcome before it goes to payroll processing. That is not a matter of how advanced the system is, but of how much structure exists in the underlying rules and data.
This task also does not stand apart from the rest of the HR process. It builds on how absence is registered and on how leave requests are processed, because both affect which hours ultimately count as overtime. And the overview that results from this is in turn the basis for preparing payroll processing. Anyone who looks at these tasks in isolation misses how errors from one step carry through to the next.
We make no statement about personnel decisions that might follow from these outcomes: separate statutory requirements apply to those, and this is not personnel advice. We calculate in freed-up hours and FTE capacity, not in job roles -- more on this can be found on the page explaining why we calculate in hours and not in people. And anyone who wants this calculation supported by a system would do well to know beforehand which data must not be used for this purpose.
Whether this task can largely be left to a system in your company depends on your collective labour agreement structure, the quality of your time registration and how many exceptions occur in practice. The free quickscan -- twelve questions, no account required -- gives an indication of what portion of the hours in your profile can be taken over by AI today. The full work scan, with the underlying calculation per task, is still under construction; we do not offer it at this time.
Vraag maar. Ik ken de kennisbank van deze site; wat ik niet weet, zeg ik erbij.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.