Before a client changes how it pays for attendance, it should know how it pays for attendance today. That sounds obvious. In practice the answer lives in three places that disagree: what people remember deciding, what the documentation says, and what the code does.
So we took the business's own description — nine working beliefs about overtime, allowances, the dashboard and payroll — and read each one against the code, not the documentation. Behaviour first, in plain language; the code reference after it.
What the code said
| What the business believed | Verdict | What the code does |
|---|---|---|
| Overtime eligibility is per employee, independent of the schedule | Partly true | Two gates must both pass: the employee's own switch and the schedule's eligibility policy. |
| Attendance types carry their own configuration | Confirmed | Approval, reason, break deduction and allowance all live on the type. |
| Factory hours run from first punch in to last punch out | Partly true | True for the biometric device. Factory is also a portal type of its own. |
| Early check-in is unpaid, absorbed by a break before the shift | Mechanism confirmed | Break lines are subtracted from worked hours. Whether that early line exists lives in the live schedules, not the code. |
| Late check-out has an hour's threshold and a short buffer | Found — interacts differently | A 10-minute grace, then a 60-minute minimum stay. Shift ends 18:00: leave at 19:00 or later, paid from 18:10. |
| Allowance eligibility is decided per site | Not as described | Eligibility and amount belong to the attendance type. A code comment records that the rate was moved off the site on purpose. |
| The dashboard flags early check-in and early check-out | Mostly not found | It flags absent, late, missing check-out, the hour band, under expected hours and pending approval. Early arrival is flagged nowhere. |
| Payroll consumes attendance directly | Only when switched on | Per payslip or per batch. Overtime never enters payroll; it has its own ledger. |
One of the nine concerned how the portal handles location. We've left it out here: the answer is the client's business, not the internet's.
Then we read it again
A single reading is a sample. The second pass read every cited function in full, every attendance and payroll file the first pass hadn't cited, and the history behind them — and left the first reading exactly as written, so the corrections show what one pass misses.
| First pass said | Correct reading |
|---|---|
| Payroll leaves out attendance on a hardcoded Friday/Saturday weekend | The weekend comes from the schedule. Friday/Saturday is only the fallback — though holidays and leave still use it. |
| Shipped salary rules are unprorated | Every shipped rule is inactive. The live structure uses different codes that exist only in the database. |
| Payroll days are rounded to sixteenths | In calendar mode that figure is replaced afterwards, so the rounding has no effect. |
| The device timezone falls back to UTC | It never does: schedule, then employee, then a fixed default zone. |
| The absent notice goes out as soon as its threshold passes | Its job runs every half hour, so up to thirty minutes later — and a threshold of zero turns it off. |
The sixth correction concerned the timing of the device sync, and stays with the client for the same reason as the location question.
What we handed back
Some questions can't be answered from code, and a report that answered them anyway would be making them up. These went back to the client, each with what we searched for:
- whether a break line before the shift exists in the live schedules, and how long it is;
- whether a short break after the shift absorbs trivial overruns;
- the prorating salary rule, which is documented but in no code file;
- the overtime rate — there is no multiplier in code; it is typed on each payment;
- and the deployed value of every setting, since every number above is a code default.
None of this was a verdict on the system. It was the only honest starting point for changing it — and it's what the attendance engine is built on now.
Read the case study: Four people, one schedule, four different ways to be paid