Linda Builds
Inside VertexHR: attendance evidence and corrections must remain traceable
Separate raw clock events, correction requests, approvals, applied revisions and downstream recalculation so changes remain explainable.
Time systems often begin with “when did the employee clock in and out?” The harder question appears when a clock event is missed, location validation fails, a device has an issue or someone requests a backdated correction: who changed what, why, and which version fed later calculations?
This article describes auditability principles relevant to VertexHR. It does not certify that every workflow or policy is enabled identically for every tenant, and it is not employment-law advice. Each organisation must confirm its own policy.
Keep original clock events separate from calculated attendance
A clock event should carry event ID, employee, timestamp, event type, source/channel and permitted context such as site or device information. Work sessions, breaks and totals are then calculated from those events.
A correction should not overwrite the raw event so completely that it appears the employee originally clocked at the corrected time. Use a correction/decision layer that explains why the displayed or payroll-ready result differs from source evidence.
Make a correction request a traceable work item
Illustrative case: an employee forgets to Clock Out and requests 18:00 the next day. Retain requester, requested value, reason, evidence/remark and request time separately from the final approved value, because the supervisor may approve a different value.
An illustrative state flow is Draft → Submitted → Approved/Rejected → Applied with actor and timestamp on transitions. If another correction is requested after application, create a new revision instead of deleting the earlier decision.
Approvers need the before/after difference and context
The review view should show original events, requested change, reason, relevant schedule/site context and expected hour difference. “Please correct my time” without before/after context is not enough for accountable approval.
Where practical, separate rights to amend source data, approve corrections and run payroll/attendance calculations. Small teams that cannot fully separate duties can use correction reports or secondary review as compensating control.
Record which downstream results were recalculated from which revision
When a correction changes worked time, record which attendance summaries, overtime candidates, leave overlaps or downstream exports were recalculated and which correction revision they used. Otherwise one report may show a new value while another still relies on the old one without warning.
If a period is locked or payroll has already been exported, a correction may need an adjustment flow rather than silent retroactive replacement. Preserve the state that supported the earlier decision and link the subsequent adjustment.
Use this as a VertexHR UAT checklist, not a blanket feature promise
Linda lists VertexHR for employee records, attendance, leave and payroll workflows and states that modules, permissions, data handoffs and service scope are confirmed before onboarding. Customers should therefore demonstrate correction scenarios with test data before activation.
Useful UAT cases include missed Clock Out, rejected correction, approved value differing from requested value, correction after period lock and re-export after amendment. Verify that the audit trail shows original/request/decision/applied revision clearly.
References: [1]
A practical starting checklist
- Keep raw clock events separate from calculated attendance.
- Capture requester, reason, evidence and before/after values for corrections.
- Separate request, approval and recalculation permissions where practical.
- Retain revision and downstream recalculation lineage.
- UAT corrections before/after period lock and repeated export.
Apply it to your business
Reliable attendance systems do not forbid corrections. They make corrections traceable so original evidence, human decisions and each calculated version can be explained later.
References
- Linda Accounting IT. (2026). Linda Business Applications. Retrieved October 1, 2026.
Numbered references support the attributed statements. Scenarios and recommendations are Linda’s examples, not verified client outcomes.
This article provides process-design guidance and illustrative examples, not an accounting, tax or legal determination or certification of every software module. Apply it with regard to your business, permissions and actual system scope.