Two Clocks, One Lock
A professional firm runs two entirely separate clocks — the one payroll pays from and the one it invoices from. Only one of them can be locked at month end, and it is not the one you bill from.
Ask a partner in an audit or consulting firm what "closing the month" means and you will get one answer. Ask the system and you will find it does two different things, on two different sets of records, sealed by two different mechanisms, at two different moments. That gap is not a bug and it is not hidden — but it is almost universally misread, and misreading it is how a firm ends up reissuing an invoice it had already sent.
The confusion is understandable because both things are called a timesheet in ordinary speech. One is the attendance record that feeds payroll: who was at work, when, plus approved overtime. The other is the engagement record that feeds billing: which hours went to which client matter, billable or not. In a firm that sells time, these two describe the same people on the same days and disagree constantly — and only the first one has a month-end lock.
Clock one: attendance, sealed by the month
The HR timesheet is a monthly roll-up per employee of attendance records plus approved overtime. It has exactly two states and they run in that order: approved, then locked. The distinction matters more than it sounds.
- Approved stores a snapshot of the figures as they stand and stamps who approved it and when — but the period is still live. The screen keeps computing from the underlying records, so a later correction still moves the numbers.
- Locked stores the same snapshot and then reads from it. The month's figures stop being a calculation and become a stored fact.
- Once locked, every write path that would alter that employee-month is refused outright: a clock-in or clock-out from the web, from the public kiosk link, from the API, or from a passkey device; a manual entry on the attendance register; an overtime record created or approved; an attendance regularisation approved.
- The refusal is a hard stop with a message naming the month, not a warning somebody can click past.
- It is bulk-capable — a whole month can be approved or locked for everyone in one action.
- Payroll consumes locked periods, which is the point of the whole mechanism.
The lock is per employee, per month
There is no single month-end switch for the firm. Each employee-month is its own record with its own status, which is genuinely useful — you can close the people whose attendance is settled and leave two disputed cases open — but it also means "is June closed?" has no single answer. It has one answer per person.
Reopening is available to the same permission that locks. It works by removing the period record, which deletes softly and is audit-logged, so the snapshot and the approval stamps remain recoverable rather than destroyed. What does not survive is the live statement that the month was ever approved and locked — after a reopen, the period simply reads as open again. If a reopened month matters to you, the evidence is in the audit trail, not on the timesheet screen.
Clock two: engagement time, not sealed by the month
Here is the part firms get wrong. Time logged against a client engagement is a completely different record on a completely different path, and nothing on that path consults the month lock. Lock an employee's June, then log eight billable hours dated the fourteenth of June against a client matter, and it saves. No warning, no refusal.
This is not an oversight so much as a different design, and once you see the design it is defensible. Engagement time is not sealed by a calendar boundary. It is sealed one entry at a time, by whatever document consumed it:
The attendance seal — a date
- Applies to a whole employee-month at once.
- Applied deliberately, by a person with the timesheet approval permission.
- Blocks writes at the gate, before anything is recorded.
- Reversible by reopening, which is soft and audited.
- Its purpose is to make payroll's inputs stop moving.
The engagement seal — a document
- Applies to a single time entry.
- Applied automatically, as a consequence of billing or paying, not as a decision.
- Does not block the entry being created — it blocks the entry being deleted afterwards.
- Not reversible: an invoiced hour cannot be deleted, only credited on the invoice.
- Its purpose is to stop a document losing the record it was built from.
The two documents that seal an hour are an invoice to the client and a payout to the person who worked it. Either one makes the entry undeletable, with an explicit message: an invoiced entry tells you to credit the invoice instead; a paid-out entry tells you it has already been paid. Those two stamps are independent, so an hour can be billed but not paid, paid but not billed, both, or neither — four genuine states, and only the fourth is freely editable.
The engagement clock is not unprotected. It is protected by the thing that consumed the hour, at the moment it was consumed — which is a stronger guarantee than a month boundary, and a much weaker one than most firms assume they have.
What this actually costs a firm
The failure mode is specific. A firm bills a client for June, sends the invoice, and treats June as closed because the timesheets were locked. In July somebody discovers unlogged June work — a site visit, a long call, a review nobody captured — and logs it with the correct June date, which the system accepts. Now the engagement's June figures have changed after the invoice was raised.
The same engagement, before and after a late June entry
Nothing here is broken and nothing is lost — the 11.5 hours are recorded, costed and visible, and they remain uninvoiced and therefore still billable. The damage is only ever in the assumption: a partner who believes locking June sealed June will read the engagement's June figures as final, reconcile against the invoice, find a difference, and spend an afternoon looking for an error that is actually a feature.
Read the other way round, the same behaviour is the reason the firm did not lose that money. A system that refused the late entry would have protected the reconciliation and thrown away 11.5 hours of chargeable work. Which of those two you want is a real choice, and it is worth making deliberately rather than discovering.
The discipline this implies
-
Stop saying "close the month"
Say which clock. In a firm where both payroll and billing run off recorded time, "June is closed" is an ambiguous sentence and the ambiguity is expensive. Two phrases, used consistently: attendance locked and engagement billed.
-
Bill from the engagement, reconcile to the engagement
Do not reconcile a client invoice against the HR timesheet. They will not agree and they are not supposed to — one counts presence, the other counts chargeable effort, and the difference is your non-billable time, which is a number you want to see rather than eliminate.
-
Run a late-entry report after every billing run
Because entries dated inside an already-billed period are accepted, the control has to be detective rather than preventive. One saved, scheduled report — billable entries created after the invoice date but dated before it — turns an invisible drift into a weekly five-minute review.
-
Treat "already invoiced" as the real boundary
The hour that cannot be undone is the invoiced one. If you want a hard boundary on billable time, the invoice is it — so raise the invoice when you genuinely mean the period is finished, not as a provisional gesture you intend to revise.
-
Decide who can reopen, and separate it
Locking and reopening an attendance period are the same permission. If the ability to unlock a month matters in your firm, that is a workflow rule you build, because the permission model will not draw the line for you.
What a buyer should check, in any system
Four questions that expose whether the two clocks are joined
If I lock an employee's June, can I still log billable client time dated in June?
What you will hear
Usually a pause, then "why would you?" — and then, on checking, yes.
How to read it
Almost every system separates the payroll clock from the billing clock, because they serve different masters. The answer you want is not "no", it is a vendor who knows which one their lock applies to without having to check.
What happens to a time entry once it has been invoiced?
What you will hear
Either "it is locked" or "you would credit the invoice".
How to read it
If an invoiced hour can still be deleted, the invoice can be left standing on records that no longer exist. That is the single worst answer in this area and it is worth testing directly rather than asking about.
Is the month lock one switch or one record per person?
What you will hear
Per person, in most systems that have one at all.
How to read it
Per-person is more useful but means "is the month closed" is not a question with an answer. Make sure whoever runs payroll knows which people are still open, because that is the list that matters.
When a period is reopened, what survives?
What you will hear
Vague answers, frequently.
How to read it
Ask specifically whether the pre-reopen figures are still retrievable and whether the reopen itself is logged. A reopen that leaves no trace turns a locked period into a suggestion.
What AWRA OpsHub does today
- A monthly attendance period per employee with two states, approved then locked, each stamping who did it and when.
- A stored snapshot taken at approve and at lock; a locked month reads its figures from that snapshot rather than recomputing.
- Hard enforcement of the lock across every attendance write path — web and API clock-in and clock-out, the public kiosk link, passkey devices, the manual register, overtime creation and approval, and regularisation approval.
- Bulk approve and bulk lock for a whole month.
- Reopen, which soft-deletes the period so the snapshot and stamps stay recoverable and the removal is audit-logged.
- Payroll consuming locked periods, which is what the lock exists for.
- Separate engagement time entries carrying the person, the date, the hours, billable or not, and both rates snapshotted at the moment of logging.
- Per-entry seals on engagement time: an entry that has been invoiced cannot be deleted, and neither can one that has been paid on a payout — each with its own explicit refusal.
What it does not do
- The month lock does not apply to engagement time at all. No code on the project time-entry path consults it, on the web or the API. Billable time can be logged into a locked month, and into an already-invoiced one.
- No submit-for-approval step by the person. A period is approved about an employee, not submitted by them — there is no "my timesheet is ready" action.
- No approval below the month. There is no per-day or per-week approval, and no partial lock.
- No approval of engagement time at all. Billable hours are not reviewed or approved by anyone before they can be invoiced.
- Locking and reopening are one permission, so there is no separation between the person who closes a month and the person who can open it again.
- No live record that a month was reopened. The evidence is in the audit log; the timesheet screen simply shows the period as open.
- No warning when a late entry lands in a billed period. The entry is accepted silently — detecting it is a report you run, not an alert you receive.
The single sentence to take from this: the lock is on attendance, and billing does not observe it. Everything else here follows from that. It is a defensible design — sealing billable time by the document that consumed it is arguably stronger than sealing it by a calendar boundary — but it is not what the phrase "lock the timesheet period" leads a professional firm to expect, and we would rather write that down than let the assumption stand.
Our take
Two clocks is the right architecture: presence and chargeable effort are different facts and forcing them into one record loses information a firm needs. What is missing is not a second lock — it is the honest label. Locking June freezes payroll's June. It does not freeze the June you invoiced a client for, and any firm reconciling one against the other should know that before month end rather than during it.
Check your own two clocks this month
Lock one employee's month, then try to log billable time dated inside it. Whatever your system does, you want to have seen it happen before it matters.
See projects, time and budget