Lifecycle
Attendance data is only trustworthy if it cannot change after you have paid for it.
In most systems it can. Somebody regularises a day in a month that was paid in March, the numbers no longer reconcile to the payslip anybody holds, and the discrepancy is found during an audit rather than during the month.
Where a day comes from
Derived by default, overridden by something explicit.
Most days need nobody to do anything. A daily sweep derives them from the holiday calendar and approved leave — so a public holiday is not something anybody marks, and neither is approved leave. The sweep deliberately runs a day behind, so leave approved late still lands on the right day.
Anything explicit takes precedence over a derived day: a correction by HR, or a regularisation the employee requested and somebody approved. The record says which it was, so a day that was corrected never looks like a day that was captured — and the sweep will not overwrite it.
- Mon 01Derivedfrom the schedule and the calendarfrozen
- Tue 02Leaveapproved, so nobody marks anythingfrozen
- Wed 03Corrected by HRan explicit entry beats a derived onefrozen
- Thu 04Regularisedmissed check-in, corrected and approvedfrozen
- Fri 05Derivedcurrent period — still editableopen
- Were they employed that day?Not yet joined, or already leftnothing
- Is it a weekend?Weekendfull
- Is it a holiday where they work?Holidayfull
- Approved leave, all day?On leavefull — or nothing if the type is unpaid
- Approved leave, half?Half dayhalf
- OtherwisePresentfull
The freeze
Payroll publishing closes the period.
The moment a payroll run locks its inputs — before anything is computed, long before anyone is paid — every attendance record in that period is frozen and further writes are refused.
A correction after that point does not rewrite history — it becomes arrears in the next run. Which is the only honest answer: the payslip somebody is holding was correct against the data at the time, and the way to fix an error is to pay the difference, not to change the past.
- Nobody is paid for a day nobody recorded —
An employee with no attendance at all is treated as present for the month, with a warning on the run saying exactly that — because the alternative, zeroing somebody's pay because a sweep did not run, is the worse failure by a distance.
- The sweep runs a day behind, deliberately —
Yesterday, not today — so leave approved late in the day still lands on the right date rather than being derived as present and corrected afterwards.
- It will not overwrite a person —
A day somebody entered or regularised is left alone by every subsequent sweep, and an unchanged day is not rewritten at all, so timestamps mean something.
- One open regularisation per day —
So a disputed day has one conversation rather than three competing requests.
- Managers see, HR corrects —
Viewing the team grid and regularising somebody's day are different permissions, because they are different responsibilities.
- Employees regularise their own —
From the portal, as a request that routes for approval rather than an email to HR that becomes a manual edit.
- Backfill is deliberate —
HR can re-derive a specific date after adding a holiday, rather than waiting for the next sweep or editing days by hand — and the re-derive reports how many it wrote and how many it left alone.
- A request that could never be approved is refused —
Somebody whose manager is not set still resolves, through a fallback approver, rather than filing into a queue nobody owns. And where HR corrects a day directly, the pending request is closed rather than left sitting in somebody's inbox.
Practical questions
Mostly about the month that was already paid.
›Can somebody change attendance for a month we have already paid?
No — and the lock happens earlier than you would expect. The period freezes when the run locks its inputs, so the figures cannot move even between calculating and paying. A correction becomes arrears in the next run.
›Do employees have to mark attendance every day?
No. Days are derived from the schedule, the calendar and approved leave. Marking is for the exceptions.
›Does it integrate with our biometric device or a clock-in app?
Not today — there is no device ingest and no punch-in surface. Days are derived, and exceptions are corrected or regularised. If capture from a device is central to how you run, that is the question to put to us first.
›Who can regularise a day?
An employee requests it from the portal, saying what the day should have been and optionally the hours they actually worked. Approving and direct correction are HR permissions. A manager sees their team's grid and their pending requests without holding either.
›What can a regularisation ask for?
Present, or a half day. It cannot be used to claim an absence or to convert a day into leave — leave goes through the leave request, which is where the balance lives.
›Does it compute overtime?
No. Expected and actual hours are both on the record, and nothing aggregates the difference. If overtime drives pay for you, that is the question to put first.
›Can we run a six-day week, or shifts?
Not today — weekends are Saturday and Sunday, and there is no shift or roster model. For a factory or a support rota that is a real limit and we would rather you heard it here.
›What happens if we add a holiday retrospectively?
Re-derive that date. The days that were derived get rebuilt; explicit signals like a check-in are not overwritten by a sweep.
Book a demo
Try to edit a paid month.
The second step is the one that tells you whether the numbers will still reconcile next year.
- Regularise a day in the current period
- Lock a payroll run’s inputs, then try the same edit again
- Add a holiday and re-derive that date
- Check a corrected day survived the re-derive