Accounts

Track and bill logged work by client, department, project, or cost center.

An account answers "who is this work for". Every work log can carry one, so hours land against a client, a department, a project, or a cost center instead of disappearing into a pile of Jira work items. That is what makes invoicing straightforward: filter or group any report by account, pick a month, and the hours to bill are in front of you.

An account is a screen of its own, with its own Worksheet, its own Access rules, and its own Settings — so a client manager can read and manage that client's hours without seeing anyone else's.

How to Create an Account

Open Accounts: In the JetTime menu, click Accounts. The list shows the accounts you have access to, with their Name, Key, and Status. Use the Status column filter to hide archived ones.

Create the account: Click Create Account and fill in two fields:

  • Name: what the account is called, for example the client's name.
  • Key: a short identifier. The key uniquely identifies the account in the API and is recorded on every work log logged to it. It must start with a letter or underscore and can contain letters, numbers, and underscores.

Click Create.

Set up access: Open Settings > Access and give the right people a permission role on the account (below).

An account opens on two tabs: Worksheet and Settings. Click the account's name in the header to rename it, and use the menu to delete it.

Examples of Accounts

  • Client accounts: one per client, to track the time and effort spent on their work and bill it back.
  • Internal departments: organize hours by department — Marketing, HR, Engineering.
  • Project-based accounts: a separate account per project, when a project spans several Jira spaces or several clients.
  • Cost centers: separate costs and financial data by area, for example Research & Development, Sales, or Customer Support.

Logging Work to an Account

When someone logs work, the Account field appears on the Log Work form if the applicable Field Scheme includes it — and that scheme also decides whether choosing an account is optional or required. So you can demand an account on client work and leave it off internal work, without a global setting.

The picker offers only the accounts the work log's author may write to, so nobody can drop hours into a client's account by accident.

Details of the form itself are in Logging Work for Accounts.

Reporting on an Account

Every account has a Worksheet tab — the same reporting you use in Reports, already filtered to that account. Pick a date range and the account's hours are there: no report to build, no filters to set. It opens grouped by Space → Work Item, and you can change the view mode, grouping, columns, totals, and time format the same way you would in a report, then export to PDF, Excel, or CSV. The exported file is named after the account.

The account filter on this tab can't be removed or widened, and the view settings you choose are shared across all account worksheets.

Outside the tab, Account is an ordinary report field: use it as a column, a grouping dimension, or a filter in any report. See Reporting on Accounts for the report side, and Building a Billable Report for a worked example.

Account Settings

The Settings tab holds the configuration you set once, split into General and Access.

General

Key and Status live here. The key stays editable after creation, as long as the new one is unique. Set Status to Archived to retire an account: it stops being offered when logging new work and grants no access anywhere it was assigned, while staying in reports so historical data keeps its account.

The account's name isn't on this page. Rename it by clicking the title in the header.

Access

The Access tab decides who may see and manage this account's work logs — which matters, because an account's hours usually become an invoice. Choose a Permission Scheme (the matrix that defines what each permission role can do), then assign roles with the Add User, Add Team, and Add Special boxes:

  • A person — an individual gets a permission role on this account.
  • A whole team — its team members all get that permission role here, and anyone who joins the team later inherits it.
  • Any logged in user — a baseline permission role for everyone on the instance, when the account doesn't need restricting.

The page previews the selected scheme, so you can see what each permission role allows before assigning anyone. Grants combine: when several rows apply to one person, they get everything those roles allow. A row can only add, so to give someone less, grant narrowly rather than adding a narrower row.

Nothing is stored until you click Save.

For the full permission model — the global permissions, the schemes, and how the two layers combine — see Managing App Permissions.

Additional Tips

  • Seeing an account is not the same as managing it. The Settings tab needs Manage Settings on the account, while Create Account and Delete Account need the View and Manage Accounts global permission.
  • Archive rather than delete. Archiving keeps every past work log's account intact for reporting; deleting removes the account and its access rows permanently.
  • Changing an account's key detaches it from the work logs that already carry the old key. Changing the key back restores them.

On this page