Self-reported time with no gate on it is a liability disguised as a convenience. A team member logs three hours against a job, nobody looks at the entry again until the invoice is drafted six weeks later, and by then the only defence against a client query is "that's what the system says", which is not a defence at all. Most practice tools treat a timesheet entry as a single flat row: logged once, trusted forever. Accupe treats it as a small state machine with a manager checkpoint built into it, because time that has been billed to a client is the one piece of firm data that genuinely needs a second pair of eyes before it becomes someone's invoice.
The lifecycle is simple to describe and, in the detail, does real work: an entry is logged, then submitted, then approved, then billed, and at two of those transitions a person above staff tier has to actively agree before the entry can move on. None of that happens by accident of the interface; it is enforced server-side, independent of whatever the browser shows. The point is not to make logging time slower, most firms want the opposite, it is to make sure that whatever speed a firm gains on capture is not paid for later with a billed figure nobody can actually stand behind. A mid-sized firm running twenty chargeable staff across a normal week can generate several hundred individual timesheet rows before Friday, and if even a small fraction of those need a genuine correction, the firm needs a process that catches the correction before it reaches a client, not a process that hopes nobody notices afterward.
Five States, Each With a Different Owner
Every timesheet row carries a status that determines who can touch it and what happens to it next. The states are not decorative labels, each one gates a different set of actions in the interface and, more importantly, on the server. The sequence only ever runs forward, or back exactly one stage on a rejection, an entry can never jump from logged straight to billed, and it never sits in two states at once, which is deliberately more rigid than most firms' previous spreadsheet-based process ever was.
- Draft (shown as "AI Draft"): a time entry the assistant has proposed from job activity, sitting for a person to check before it becomes real
- Logged: a confirmed entry the staff member owns and can still edit freely
- Submitted: sent up for review; the staff member has said "this is accurate", and the grid for that entry stops being freely editable
- Approved: a manager tier or above has signed off; the entry is now locked short of an explicit override
- Billed: the entry has been carried into an invoice and is treated as closed
Why the Grid Locks Itself at Submission
Submitted, approved and billed are treated as protected statuses in the interface. Once an entry reaches any of the three, the day's grid becomes read-only for the person who logged it, so a staff member cannot quietly adjust an hour after a manager has already reviewed it, and a manager cannot accidentally overwrite a figure a client has effectively already been billed for. The lock is not absolute for everyone; a manager or admin with the appropriate override can still edit a protected row when there is a genuine correction to make, but the default behaviour protects the number that downstream systems, profitability reports and invoices, are already relying on.
This is a deliberate trade against pure flexibility. A firm could, in principle, let every team member edit their own time forever and rely on trust. Accupe's design assumes that trust and audit trail are not substitutes for each other, and that a billed figure should be exactly as stable as the invoice it fed. The payoff shows up months later rather than on the day itself: a firm reviewing a client's query about a bill from the previous quarter does not have to reconstruct what happened from a scatter of remembered edits, the status on the row, together with who moved it and when, is the entire history of that hour of work, from the moment it was typed to the moment it appeared on the invoice. The same status field also makes the review itself manageable at scale: a manager can filter the whole team's grid down to submitted rows and work through exactly the queue awaiting a decision, rather than hunting page by page for which of two hundred rows happen to need attention this week.
The Manager-Tier Gate on Approval and Rejection
Approving or rejecting a timesheet is restricted to the manager, admin and company tiers, and the restriction is enforced on the server, not only hidden from the button in the interface. A plain staff member calling the approval or rejection endpoint directly, rather than through the interface, is refused with a clear permission error rather than being allowed through by an oversight in an older, more permissive database policy the route intentionally no longer relies on. Every lookup is also scoped to the caller's own firm: a manager at one firm cannot approve, reject, or even discover, a timesheet belonging to a different firm on the platform, whatever ID they happen to try.
The gate exists because approval is not a formality, it is the point at which the firm is stating that a number is fit to bill. Letting anyone rubber-stamp their own time, or a colleague's time, at will would make the approved status meaningless. Restricting it to manager tier and above keeps the signal real, and enforcing it server-side rather than only in the button the interface shows means the rule holds even against a direct, scripted call to the underlying route, not only against the ordinary use of the page. It also closes a specific, easy-to-overlook gap that a purely client-side check leaves open: a browser can be told not to show the approve button to a staff member, but a browser cannot be trusted to stop a request that never came from that button at all. Moving the check onto the server means the firm is not relying on the interface behaving itself, it is relying on the actual database write being refused at the source, which is the only place a refusal is genuinely enforceable.
Rejection Sends Time Back, It Does Not Delete It
Rejecting a submitted entry does not move it into some separate rejected bucket that then has to be resurrected. It returns the entry to logged, exactly the state it was in before submission, so the staff member can correct it and resubmit through the same flow rather than starting again from nothing. A manager can attach a short written reason when rejecting, so the staff member is not left guessing what was wrong with the entry, whether it was the wrong job, an implausible duration, or a task that should have been billed to a different client entirely. Rejecting an entry that has already been sent back is treated as a success rather than an error, so a manager double-clicking or retrying the action does not produce a confusing failure message.
This design choice, sending time back rather than marking it dead, matters for how a firm actually uses rejection day to day. A manager reviewing twenty submitted entries before a billing run is not making a permanent judgment about anyone's honesty; they are catching the ordinary mistakes, a duration typed in the wrong units, a job picked from a dropdown one row above the one intended, that happen in any manually entered dataset. Treating rejection as a routine correction step, not a disciplinary one, keeps the review genuinely useful rather than something staff learn to dread and route around. A firm that uses rejection this way tends to see the same handful of correction categories recur, a task logged against the wrong job code, a duration that clearly includes an interruption nobody remembered to pause for, which is itself useful information: it tells the manager where the logging habits in the team could use a five-minute reminder, rather than where an individual needs a difficult conversation.
AI-Drafted Entries: A Head Start, Not an Autopilot
Some rows arrive on the grid already populated and flagged as an AI draft, a suggested entry based on the activity the system observed against a job, rather than a manually typed line. The point of the draft status is speed without surrendering judgment: the suggestion sits there in a visibly different state until the team member reviews it, corrects the duration or the job if needed, and confirms it into a genuine logged entry. A draft is never treated as billable time on its own; it has to pass through the same logged, submitted, approved sequence as time a person typed in by hand, which means the draft status buys speed at the point of capture without buying its way past any of the review the rest of the lifecycle insists on. The practical effect for a busy team member is that the blank-page problem, sitting down on a Friday afternoon trying to remember what was worked on for six different clients across the week, mostly disappears; the entries are already sketched out, in the right shape, waiting for a quick check rather than a from-scratch reconstruction of a week that has already faded from memory.
From Billed to the Invoice
Billed is not the end of the story, it is the handoff point. Once time has been approved and carried into billed status, it feeds the firm's invoicing and, in aggregate, the job profitability picture the firm reviews separately: hours logged against a job compared with the fee agreed for it, rolled up by client and by team member. The timesheet lifecycle is deliberately the narrow, mechanical part of that story: an accurate, approved, tamper-resistant record of who did what, for how long, on which job. What the firm does with that record, how it prices the next renewal, whether a client relationship needs a fee conversation, is a separate decision made with separate tools, and it is a decision worth exactly as much as the record underneath it is trustworthy, which is the entire point of gating approval in the first place. A firm billing fixed-fee rather than by the hour still benefits from the same discipline even though the client never sees an hourly figure at all, because the approved time record is what tells the firm, internally, whether a fixed-fee engagement is actually running at the margin the firm assumed when it quoted the fee, or quietly eating more hours than the price was ever built to cover.
What It Does Not Do
The lifecycle does not set billing rates, calculate an invoice total, or decide whether a job should be billed fixed-fee or by the hour, those remain firm decisions made elsewhere in the platform. It does not automatically write off unbilled time or apply a discount; a manager makes that call explicitly when preparing the invoice. And it does not judge whether the hours logged were reasonable for the work done, that is still a human review, the approval step simply guarantees that the review actually happened and is recorded against a named approver and a timestamp, so the firm can always answer who signed off on a figure and when, even if it cannot answer, on the platform's behalf, whether the figure was the right one to charge in the first place.
Closing
A timesheet is only as trustworthy as the process that turns a typed number into a billed figure. Accupe's lifecycle gives that process a shape: logged time a person owns, a submission that hands it up for review, a manager-tier approval that has to happen before the number is treated as settled, and a lock that protects the figure once it has been signed off. None of it removes judgment from the firm, it just makes sure judgment was actually applied, by the right person, before the client ever sees the number.
