Sick Leave Processing Agent

Every morning, new sick leave notifications arrive in the system. On Mondays after flu waves, there can be dozens. Each one triggers a cascade: match to the correct employee, determine whether it is an initial or follow-up certificate, calculate the continued pay entitlement period, check the absence history for prior related illnesses, send the statutory notification to the health insurer, adjust payroll, notify the line manager - without disclosing the diagnosis. And for long-term cases: monitor the threshold for return-to-work programme obligations.

This is not an exception. This is the steady state. The average across the EU is 7 to 11 sick days per employee per year, with significant variation by country and sector. In an organisation with 2,000 employees, that means thousands of absence days annually - each one an administrative event with statutory deadlines and consequences for missed notifications. Continued pay obligations alone represent one of the largest non-discretionary cost items on any employer’s books. The problem is not the complexity of any individual sick note. The problem is the volume combined with zero error tolerance.

Where the errors occur

This agent follows the Decision Layer principle: each decision is either rule-based, AI-assisted, or explicitly assigned to a human.

Continued pay entitlement calculation sounds simple: a defined number of weeks of continued pay from the start of incapacity, as mandated by employment law. In practice, it is one of the most frequent error sources in payroll. Three constellations cause the majority of problems.

Prior illness offsetting. If an employee reports sick again within twelve months with the same underlying condition, a new entitlement period does not start. Previous absence days count against the total. In practice, this regularly fails because nobody systematically checks the absence history against diagnosis groups. Result: the employer pays full continued pay when the entitlement was already exhausted - or cuts off too early when the condition is actually a new illness. (UK: Statutory Sick Pay has different qualifying rules but the same offsetting logic for linked periods of incapacity.)

Initial versus follow-up certificates. When a sick note arrives, an immediate determination is required: is this a new absence or an extension of an existing one? This determines whether the entitlement period resets or continues. In manual processing, a single incorrect date comparison can invalidate the entire deadline calculation.

Public holidays and shift patterns. In organisations with variable working schedules, continued pay calculation is among the most error-prone items in payroll. Public holidays falling within an absence period are misclassified, shift premiums are not correctly accounted for.

Every one of these errors generates rework: correction runs, reclaim processes, and in the worst case, liability risks during audits.

Four deadlines, four recipients, zero margin

A single sick note simultaneously affects multiple processes and systems:

Sick note arrives
    |
    +-- Payroll: continued pay or statutory sick pay?
    |
    +-- Health insurer: statutory notification (legal deadline)
    |
    +-- Line manager: notification without diagnosis
    |
    +-- Threshold monitor: cumulative absence days, long-term trigger

Each of these four channels has its own deadlines, its own recipients, its own data protection rules. The health insurer notification must go out within the statutory window. The line manager may learn that someone is absent - but not what the diagnosis is. Payroll needs to know whether continued pay or statutory sick pay applies. And the threshold monitor must accumulate absence days in the background, across months, across interruptions.

Manually, that means: four different systems, four different processing steps, for every single sick note. At a hundred notifications per month, a manageable process becomes a fragile construct of reminders, spreadsheets, and hope.

Rule engine, not guesswork

The Sick Leave Processing Agent decomposes this process into its individual steps and assigns each step a decision-maker: rule engine, AI analysis, or human.

The overwhelming majority of these steps are deterministic. Matching the certificate to the employee via ID numbers: rule engine. Date comparison for initial versus follow-up determination: rule engine. Continued pay deadline calculation: rule engine. Health insurer notification within statutory deadlines: rule engine. Manager notification without diagnosis data: rule engine.

Only at one point does the process require genuine analysis: prior illness offsetting. Here, the absence history must be checked against related diagnosis groups within the twelve-month window. This is not a yes-or-no comparison but pattern recognition across medical categories. AI-assisted, but with a transparent decision protocol - because every offsetting decision must withstand scrutiny in an employment tribunal.

The long-term absence threshold: where automation stops

For long-term illness, the agent monitors cumulative absence duration. When an employee reaches the statutory threshold for a return-to-work programme - typically after several weeks of cumulative absence within a twelve-month period - the obligation to initiate a structured return-to-work process is triggered. The agent detects the threshold reliably - even when the qualifying days are spread across multiple shorter absences, distributed over months, with interruptions in between. (UK: the equivalent trigger for Occupational Health referral typically follows employer policy rather than statute, but the tracking logic is identical.)

But: the agent does not initiate the return-to-work conversation itself. It reports the threshold crossing to HR. The human decides on timing, format, and approach. This is not a technical limitation - it is a deliberate architecture decision. Return-to-work is a conversation between people about the future of an employment relationship. No algorithm decides when the right moment for that conversation is.

This boundary is characteristic of the entire process: the agent handles volume, deadlines, and statutory notifications. The human retains the decisions that require judgement. In the return-to-work context, that also means: only about half of eligible employees actually receive a formal offer - not because organisations ignore the obligation, but because the threshold crossing is simply missed in manual processes. An agent that reliably counts cumulative absence days does not solve a single return-to-work challenge. But it ensures that HR learns about every single case.

Health data requires its own protection architecture

Sick leave records constitute special category personal data under GDPR Article 9. This demands more than access controls and encryption. It requires an architecture that enforces data minimisation by design.

The agent processes absence periods and diagnosis groups - but only where strictly necessary for deadline calculations. Specific diagnoses are not forwarded to line managers, not stored in notification text, not logged in the Decision Log. Every processing rule is documented in the employee representation agreement and auditable.

That sounds self-evident. In the reality of manual processes, it is not. When sick notes are forwarded as PDFs via email to the line manager, there is a data protection problem - even if nobody caused it intentionally. A rule-based agent does not have this problem structurally, because the information architecture prescribes which data flows to which recipient.