Skip to content
EbanEbanEban Docs

Resolve attendance problems

Use Attendance (Time & Attendance → Attendance) to review and resolve missed punches, exceptions, and disputes that require manual intervention.

Instead of listing every failed record, the queue groups the work into three fixed tiers:

Tier Meaning
You decide Questions the system genuinely cannot work out alone, for example whether an absent-looking day was a real absence, or whether someone who scanned on days they were marked absent actually worked.
Patterns One wrong fact behind many days, which correcting rebuilds all of. For example a scan that cannot be matched to an employee, a day no schedule covers, or an unclear pay contract.
System status Informational: what the system is working on, or waiting on you to set.

Narrow the queue with the window filter: 30, 90, 180, or 365 days back, defaulting to 90 days. A section rail jumps straight to each tier and always shows the period being looked at. The page refreshes itself when related data changes, and a manual Refresh button re-reads it.

Each item states the problem and its scale, such as “marked absent on 5 days they scanned in June 2026”. To act on one:

  1. Tick the question(s), or act on a single row directly.
  2. Choose the appropriate action.
  3. If the action changes attendance, confirm it and give a short reason: “Why? A few words. This is what the history will show, and who asked.”
  4. The queue reloads, and answered items disappear.
  • Attendances lists scheduled days per employee: date, schedule (with a Flex group indicator where relevant), branch, employee, phone, arrival time, monetization, status, and exit. Search by employee, filter by date range (a range is always applied) and grouping, and add a comment to a searched day.
  • Punches is the audit-level record of every raw scan: bound to a shift, set aside, or flagged. Bound rows link straight through to the attendance; unplaced and flagged scans can be reviewed and re-placed here. Search by employee, filter by scan date range (always pinned), refresh manually, and export to Excel or PDF.
  • History logs every correction: when it happened, what changed and the intent, the employee, who made it, the reason, and the Rebuild state that ran afterwards. You can Reopen this question to take a past decision back, giving a reason, but only if the underlying condition is still true. The list refreshes live, and an untouched log reads “Nothing corrected yet”.

All tabs export to Excel or PDF.

Many rows across the tabs lead to the day view: one employee, one day, identified by their name and date. An absent day opens the same view showing “(no attendance)” rather than failing. At the top, status badges show anything affecting the day:

  • Consumed by Payroll Run: the attendance has been taken into a payroll run and can no longer be freely edited.
  • Shift reassigned: the employee’s shift for the day was moved. See below.

Sections show:

  • Overview: the verdict, time tracking (duration, lateness, hours), absence details, and any parked scans.
  • Punches: the individual scans for the day, removable where allowed.
  • Session details: the shift the day was measured against.
  • Monetization: how the day values for payroll, and any monetization failures.
  • Comments: notes attached to the employee’s day.

If an employee was expected to work one shift but attended another, you can reassign their attendance to an eligible shift. This is common with flex groups, and a reason is required for every reassignment.
Eligible replacements are shifts the employee is assigned to on that date. Reassignment must stay within the same flex group. It is blocked if the attendance is associated with a payroll run, has already been monetized or paid, or is still in draft.

After reassignment, the day reloads and a manual shift change entry is added to the History, recording who made the change, the original and replacement shifts, and the reason provided.