To find Jira users who still cost money, list users with Jira product access, trace every group or role that grants it, then filter for users without a current owner or business reason. Billing exports alone do not explain the access path.
Why this matters
The users who still cost money are not always the users who look suspicious first. Some active users are in the wrong product, some inactive users are required service accounts, and some former contractors remain in default or team groups.
A strong review connects billing, product access, group membership, and ownership. That lets admins remove the right access path and explain why other rows stayed.
For the query users still cost money jira, the useful answer should help an admin decide what to check now, which rows to hold out, and which proof should survive after the change. That is why this page stays inside a narrow operational boundary instead of becoming a general governance essay.
Working scenario
A Jira admin receives a billing export and an inactive-user export. The overlap is useful, but the admin still needs to know which users can access Jira through product roles, default groups, or synced groups before taking action.
Start with product-access users
The first list should be users who can access Jira, not every account in the organization. Product-access eligibility is the practical link between the user and Jira license cost.
Add cleanup signals
Layer in last activity, employment status, contractor end dates, team changes, and owner notes. These signals help prioritize but should not override the access-path review.
Trace all groups that grant access
A user may belong to several Jira access groups. Document each access-granting group, including default groups, before deciding whether the row still costs money for a reason.
Mark the action owner
Every candidate should have an owner: the Jira admin can remove local access, a manager can approve a business decision, or an identity owner can change synced membership. No-owner rows become repeat drift.
Decision table
| Signal | What to verify | Decision or evidence |
|---|---|---|
| User appears in billing count | Current Jira product access and access-granting path | Keep as candidate until path is explained |
| User is in multiple access groups | Whether any group remains after planned removal | Do not mark resolved until all paths are reviewed |
| No owner can justify access | Employment, team, and project context | Approve removal or suspend according to policy |
| Identity-managed group | Source system and provisioning owner | Route request to identity team with evidence |
Common mistakes
Most cleanup errors happen when an admin treats a partial signal as a complete answer. These are the failure modes to watch for on this topic:
- Searching only for users with no recent login.
- Ignoring users who cost money through a second access group.
- Assuming the billing export explains why access exists.
- Leaving identity-managed rows in a local admin backlog.
Checklist
- Export or identify users with Jira product access.
- Join the list with inactivity, HR, contractor, and team-change signals.
- Trace all product-access groups and default groups.
- Assign an owner and action lane to every candidate.
- Record the access path before removing or suspending access.