The question behind the invoice
Jira administrators are often asked to find inactive Jira users, unused Jira licenses or a way to reduce Jira license cost before renewal. The hard part is not producing a list. It is knowing what the available data actually proves.
License Radar for Jira takes a narrower approach: it identifies review candidates from supported Jira access and observable issue-update activity, then shows the evidence and cost assumption beside the recommendation. It does not turn missing login data into a claim that someone never used Jira.
Four useful distinctions
- Observed data — for example, an issue update associated with an assignee, reporter or creator.
- Inference — a candidate classification based on the configured threshold and available activity.
- Administrator input — the cost assumption, protection rule or review decision your team supplies.
- Estimate — the modelled cost associated with access worth reviewing, not money already saved.
Keeping those distinctions visible makes a Jira license audit easier to defend with finance, procurement and the person who owns the access.
A calm renewal workflow
- Run a completed, read-only scan of the installed Jira site.
- Check coverage and separate strong candidates from insufficient evidence.
- Open Candidate Evidence and confirm the activity source, threshold and configured cost.
- Ask the owner or manager before changing access outside the app.
- Record Keep access, Candidate for removal or Protected in the review queue when Pro is enabled.
- Build an Action Plan for the approved follow-up and return after a later scan to verify what is still present.
What this workflow cannot answer
It cannot provide a site-wide login metric, prove that an account was never used, establish a causal group-to-product assignment path when Jira does not expose it, or confirm what an Atlassian invoice will do after an external decision. Those are important limits, not footnotes.
Start with Getting started, then read Candidate Evidence and Review workflow.