Blog › Tools comparison

Jira vs. HourTab for retainer client hours visibility

July 11, 2026 · ~14 min read

Jira is the most widely deployed project tracking tool in software development. Hundreds of thousands of development teams — from two-person studios to enterprise engineering orgs — run their sprints, backlogs, and roadmaps in Jira. If you’re a freelance developer, an agency developer, or a small dev shop delivering work on a monthly retainer, Jira is almost certainly in your workflow.

But if your client is on a monthly retainer with a hours cap — “30 hours per month at $150/hr” — Jira cannot answer the question they will ask every two weeks: “How many hours do we have left this month?”

This is not a failing of Jira. Jira was designed to manage software project work: issues, sprints, epics, backlogs, and team velocity. The gap between what Jira tracks and what a retainer client needs to know is architectural. This post explains that gap clearly, covers the Atlassian ecosystem’s time-tracking options, and shows how Jira and HourTab fit together in a complete retainer workflow.

What Jira actually tracks

Jira’s data model is built around issues — bugs, stories, tasks, and epics. Issues belong to projects, are organized into sprints (for Scrum teams) or queues (for Kanban teams), and roll up into epics for thematic grouping. The reporting layer shows sprint completion rate, velocity (story points completed per sprint), burndown charts (issues remaining per sprint), and cumulative flow diagrams.

None of these concepts maps to a retainer billing cycle. A Jira sprint is a time-boxed development period, typically one or two weeks long, used to plan and deliver a set of issues. A retainer billing cycle is a calendar period — almost always one month — during which a client’s pre-purchased hours are consumed against a cap.

These two concepts are completely unrelated. A dev team might run two-week Jira sprints that cross the billing cycle boundary. The retainer billing cycle resets on the 1st of each month regardless of where the current sprint falls. Jira has no awareness of the billing cycle, no monthly hours cap field, and no report that shows “18 of 30 hours used · 12 hours remain · resets September 1.”

Does Jira have time tracking?

Jira includes a basic time-tracking feature in its classic issue view: the Original Estimate and Time Spent fields. An issue can be estimated at 4 hours and have time logged against it by a developer — “spent 2h 30m” — with progress tracked on the issue’s time-tracking widget.

This native feature is minimal and intended for project estimation, not billing. It doesn’t aggregate across billing cycles, doesn’t know what a retainer cap is, and doesn’t produce a client-facing view of hours consumed vs. remaining. In Jira Cloud (the current default), the time-tracking feature is even more limited than in Jira Server and Data Center.

For serious billing-level time tracking in the Atlassian ecosystem, teams use Tempo Timesheets — the most widely adopted time-tracking add-on on the Atlassian Marketplace. Tempo adds a proper time-logging layer on top of Jira: timers, manual entry, calendar view, approval workflows, and billing reports by user, project, or “account” (Tempo’s term for billing entities).

Tempo is the right answer for “how do my developers log hours against Jira issues and generate a billable hours report?” It is not a retainer management tool. Tempo has no concept of a client-specific monthly hours cap, a billing cycle reset date, or a public URL the client can check to see their remaining balance. Tempo answers the agency’s internal question (“how many hours did we log for ACME Corp this month?”), not the client’s external question (“how many hours do I have left?”).

Jira’s customer portal: not a retainer hours view

Atlassian has a customer-facing surface: Jira Service Management (formerly Jira Service Desk), which includes a customer portal for submitting and tracking support tickets. This is designed for IT help desks and managed service providers — organizations that need a customer intake form for incidents and service requests.

Even in agencies that use Jira Service Management for client communication, the customer portal does not answer the retainer hours question. The portal shows the client their submitted tickets and their statuses. There is no retainer hours balance in the portal because Jira Service Management doesn’t have a retainer billing concept.

For Jira Software (the project management product, not the service desk), clients can be added as project members with reporter or viewer permissions. With this access, a client can log into Jira and see the issue backlog, the sprint board, and any roadmap views the team has configured. This is genuine project visibility — the client can see what’s being worked on, what’s in the backlog, and what was shipped in recent sprints.

But project visibility is not hours visibility. A client who can see the sprint board still cannot answer “how many hours do we have left this month?” from that view. The sprint board shows issue statuses. It doesn’t show a running hours tally against the retainer cap. The client can see that 8 issues were completed in the current sprint — but they have no way to translate that into hours consumed or hours remaining without asking the developer directly.

Additionally, Jira requires every user — including client members — to create an Atlassian account. A client who doesn’t want another SaaS account, or whose company’s IT policy restricts third-party tool access, cannot see anything in Jira at all. The retainer hours question now has a mandatory account creation step between the client and the answer.

The agency retainer workflow gap

The typical setup for a small dev agency billing clients on monthly retainers:

The agency runs Jira for all project work — client issues get logged, sprints get planned, work gets delivered. Developers log time in Tempo (or an external tracker). At month end, the account manager exports a Tempo report, calculates the hours total, and sends an invoice with the hours summary.

The client receives the invoice and, for the first time that month, sees their hours breakdown. If the hours consumed are close to the cap, the client may be surprised — they had no visibility during the month to anticipate the end-of-cycle number. If hours are well under the cap, the client wonders whether the retainer is sized correctly.

Between invoices, the client emails their contact at the agency: “Can you let me know where we are on hours? We’re thinking about adding a new feature but don’t want to go over.” The account manager checks Tempo, replies with a number. A week later, another email. The status-request loop runs in parallel with the project work, adding admin overhead to every retainer client relationship.

This loop is structural, not personal. The client is not being demanding — they need the information to make decisions. The agency is not being negligent — the information simply isn’t accessible to the client without an intermediary step. The tool (Jira + Tempo) handles the agency’s workflow but doesn’t expose the client’s balance in a self-serve format.

HourTab closes this gap with a single URL. Each retainer client gets a page that shows their current hours used, hours remaining, cycle reset date, and work log. The client bookmarks it. They check it when they’re deciding whether to add a feature. No email to the account manager. No wait for a Tempo export. The answer is always current after each weekly CSV upload.

The Tempo + HourTab workflow for Jira teams

For agencies and developers using Jira and Tempo:

Jira manages the project work: issues, sprints, epics, roadmaps. All client work lives in Jira. Developers move issues through the sprint board. Clients with Jira access can see the project status.

Tempo Timesheets captures billable hours: developers log time directly on Jira issues (or via the Tempo calendar view). Tempo tracks time by user, by Tempo account (which maps to a client), and by date range. At month end, the agency pulls a Tempo billing report for each client account.

HourTab provides the client-facing hours URL. The account manager (or developer) exports Tempo’s timesheet data as a CSV filtered by client account and current billing period, then uploads it to HourTab. HourTab generates a public URL showing the client’s hours used, hours remaining, and work log. The URL is sent to the client once and they bookmark it. It updates with each subsequent CSV upload — once a week, ideally.

The workflow is one CSV export and one upload per week per client, typically 3–5 minutes. In exchange, the status-request emails stop arriving. The client has their answer without having to ask.

For teams not using Tempo, the same workflow applies with an external time tracker: Toggl, Clockify, Harvest, or any other tracker that exports a CSV of time entries by client and date range. The time tracker is the source of truth for hours; HourTab is the client-facing display layer.

Jira vs. HourTab: feature comparison

Capability Jira HourTab
Issue and bug tracking Yes No
Sprint / Scrum planning Yes No
Backlog and roadmap management Yes No
Native time tracking (timers) Basic (via Tempo add-on) No (CSV import)
Retainer billing cycle model No Yes
Monthly hours cap per client No Yes
Hours remaining display No Yes
Billing cycle reset date No Yes
Public client URL (no login) No (Atlassian account required) Yes
Client access without account signup No Yes
Work log for client (per session) Issue history + comments CSV rows (date, duration, description)
Rollover rules for unused hours No Yes
Multi-client retainer management Via projects / accounts (with Tempo) Yes
Purpose Software project management Retainer hours transparency

Why the Atlassian account requirement matters

Every person who accesses Jira — whether as a team member, a client viewer, or a project guest — needs an Atlassian account. This is a hard requirement. There is no guest or anonymous view in Jira that bypasses account creation.

For many retainer clients, this is a meaningful friction point:

Enterprise and mid-market clients frequently operate under IT policies that restrict which SaaS tools employees can create accounts with. An Atlassian account may require IT approval, SSO configuration, or security review. The client’s project lead wants to check their hours balance; their IT department needs to approve the tool first.

Small business and startup clients often have SaaS fatigue — they’re already managing accounts across a dozen tools. A client who received a Jira invitation, needs to create an Atlassian account, complete the email verification, find the right project, and then discover they can’t see their hours balance anyway is not going to use this channel. They’ll email instead.

HourTab’s architecture inverts this entirely. The client receives one URL. They click it. No account. No email verification. No app to install. The URL opens in any browser — desktop, mobile, tablet — and shows the hours balance immediately. The client can bookmark it and return any time. The URL is designed to be checked in 10 seconds, not to be logged into.

Who benefits most from Jira + HourTab

The combination is most valuable for:

Dev agencies billing clients on monthly retainers. A 3–10 person agency running Jira for project work typically has 5–20 retainer clients, each with their own hours cap. Account managers spend meaningful time fielding hours-status questions from those clients every month. HourTab gives each client their own URL, converting a recurring manual process into a 5-minute weekly upload task.

Freelance developers using Jira for personal project management. Some independent developers adopted Jira for their own workflow or use it because their clients require it for project visibility. Their client has Jira access for project tracking but still needs a separate channel for hours visibility. HourTab fills that gap without adding more Atlassian infrastructure.

Boutique software studios with client-facing retainers. A small studio might bill two or three long-term clients at 40–80 hours per month per client. At that scale, the hours question arrives weekly, not monthly. A live URL per client eliminates the most repetitive account management task in the business.

FAQ

Can Jira track retainer hours for freelance clients?

Not in the retainer-billing sense. Jira manages issues, sprints, and project velocity — not billable hours against a monthly cap. There is no monthly retainer cycle concept in Jira, no client-facing hours balance display, and no built-in way to show a client how many hours remain in their current billing period. For billable hours tracking in Jira, teams typically use Tempo Timesheets as an add-on. For client-facing retainer hours visibility, they need a separate tool like HourTab.

Does Jira have time tracking built in?

Jira has a basic time-logging feature (Original Estimate and Time Spent per issue), but it’s minimal and not designed for billing. For real billable hours tracking against clients, most Jira teams add Tempo Timesheets. Tempo handles the internal time-tracking need well but doesn’t produce a client-facing retainer status page. Tempo export → HourTab upload is the complete workflow for client-facing hours visibility.

Can Jira clients see a retainer hours balance?

No. Jira’s client access (via project membership) shows the issue backlog, sprint board, and roadmap — not a retainer hours balance. Jira Service Management’s customer portal shows support ticket status, not retainer hours. Even with full Jira access, a client can’t see their hours remaining without asking the developer or agency to run a Tempo report. HourTab gives the client a self-serve URL instead.

How does Tempo work with Jira for retainer billing?

Tempo Timesheets adds proper time-logging to Jira: timers, manual entry, timesheet approval, and billing reports by client account. It answers the internal question (“how many hours did we bill this client?”) well. It doesn’t answer the client’s external question (“how many hours do I have left?”) because there’s no no-login client URL. The Tempo export → HourTab upload workflow gives teams both: internal tracking via Tempo, client-facing balance via HourTab.

Can I use Jira and HourTab together?

Yes. Jira handles project management (what gets built, in what sprint, in what priority order). A time tracker — Tempo inside Jira, or an external tool like Toggl or Clockify — records billable hours. HourTab takes the time-tracker CSV export and generates a public URL per retainer client. The three tools cover three distinct jobs and don’t conflict. The client gets Jira access for project visibility and a HourTab URL for hours visibility — complete information, two formats.


HourTab gives retainer clients a live hours URL from a time-tracker CSV — no Atlassian account, no client login, no portal required. Works alongside Jira + Tempo, or any time tracker that exports a CSV. Free tier covers one client. Start free →