Jira timesheet approvals: one step, per project, with the reason attached

Jira’s work log has no approval in it — time is final the moment it is saved. Calibro Track puts one step between logging and counting: people submit a week, an approver for that project decides it, and the result is what reports and payroll see.

Written 2026-09-09 from the app’s own documentation. Everything here is shipped, not planned.

Why a timesheet needs an approval step

Anything that turns hours into money — payroll, client invoices, a utilization number someone is held to — needs a figure that has stopped moving and a record of who said so. Without a step, the timesheet is whatever it happened to say when the export ran. Calibro Track keeps the step to one decision, because the approver on most teams is a lead, not a committee, and a chain that nobody needed is a week of hours stuck in it.

Who can approve

There are three roles and no permission scheme of the app’s own; what you can see follows what you can already see in Jira.

Approvers are set per project in Settings → Approvers. A project can have several; any one of them can decide, and the entry leaves the others’ queues once decided. One person can approve for as many projects as you like. It is the one thing worth doing on day one: time submitted against a project with no approver has nobody to decide it, and Settings marks the pane until someone is assigned.

Submitting

Time starts as a draft. A person submits one entry, a day, or the whole week from the timesheet rail — Submit week says how many hours it will send — and can recall anything before it is decided. Entries a timer left flagged (Needs a note, Check this) are held out of every submit until settled, so an approver is never asked to decide time the app itself has a question about. Teams that run fortnightly switch Submission period to bi-weekly in Team defaults.

The approvals queue

The Approvals tab opens on Waiting on you, grouped by person and week, with a count on the tab that matches the queue behind it. Approve all clears someone’s week in one action; tick entries and use Approve selected; or decide row by row with the tick and cross. Rejecting asks for a reason. It is optional, but it is the difference between someone fixing the entry and someone resubmitting the same thing.

Group by

Person is the default, because approving is a decision about someone’s week. Ticket answers the question about one issue instead, spanning weeks.

Filters

By project, by age (this week, or older than a week), and by outcome — which is how you find something you already approved.

From the issue

An approver looking at an issue sees the submitted time on it in the issue panel and can decide there, without going to the queue.

What a decision does

1. Approved entries lock. With Lock time once approved on in Team defaults, nothing changes them without an approver reopening them. Who decided, and when, is recorded on the row.
2. Rejected entries go back to the person as drafts with the reason attached, and the next Submit week picks them up once fixed.
3. Every surface redraws. The owner’s timesheet and the other approvers’ queues update the moment the decision is written, with no refresh.

Approving by saying so

Calibro Track ships its own Rovo agent, and it handles the queue for approvers. What is waiting on me? answers per person with totals and the entries behind them. Approve Alice’s week confirms the person and the total, shows Rovo’s review card, and decides. Reject Bob’s Tuesday, wrong issue sends the reason along, and the agent asks for one if you did not give it. The agent can decide exactly what you could decide on the Approvals tab, in your name, in the same audit trail, and nothing else. Rovo time tracking →

When Jira moves or deletes the issue

Jira does not keep issues still. When an issue moves to another project, every entry on it takes the new key and, by default, follows it — a submitted entry leaves the old project’s queue and appears in front of the new project’s approver. An admin can choose instead to leave already-approved time under the project it was approved in, which matters when that time has already been paid. When an issue is deleted, its time is kept and marked Deleted issue wherever it appears; an approver can still decide it, because the hours were really worked.

What approved hours feed

Reports filter by approval status, so a billing report counts only approved time. The payroll export takes approved hours by default and, before anything downloads, names everyone who is not in the file and why — usually a week nobody has approved yet, with a link to open it. Every export is numbered, and every entry remembers which file it went into, so the queue can say whether a week was ever paid. Payroll export →

What it deliberately doesn’t do

• No multi-level chains. One decision per entry, by any approver on the project.
• No period close. Entries lock individually when approved; there is no “the month is closed” switch that stops new time being logged into it.
• No reminders. Nothing nudges people to submit or approvers to decide. The badge on the Approvals tab is the signal.
• Self-approval is recorded, not prevented. An approver who submits time on a project they approve for can decide it; the audit trail shows the same name in both places. If your controls need those to be different people, assign approvers who do not log time on the project.