What billable access means in practice
Atlassian's billing documentation is direct on the core rule: pricing is based on the number of users who can access the app. For monthly subscriptions, users can count toward billing as soon as they are tied to the subscription, even if they never accept the invite or never log in.
That one point explains a lot of renewal pain. A "visible user" is not automatically the same thing as a "currently active user," and neither of those is automatically the same thing as a "non-billable user."
From an admin point of view, billable access means:
- the user is still attached to an app subscription in a way Atlassian counts
- the access path still exists
- the row still needs a real decision before it stops costing money
That is why "we found 50 inactive users" is not the same thing as "we found 50 safe savings decisions."
Product access is the start of the path
Atlassian's documentation on how product access works makes the structure clear:
- groups can assign access
- groups can also be used for in-app permissions
- default groups automate part of the access process
That means billable access is often the result of a path, not one isolated mistake.
One user may still count because:
- they are still in a default access group
- a synced or custom group still grants the app role
- they still retain access through the broader access model even if nobody intended that row to stay expensive
This is why Why Default Groups Quietly Inflate Atlassian License Spend is such an important companion page. Default groups are one of the main ways the billing path stays invisible to teams that are only looking for last-login dates.
The states people confuse with one another
| State | What it tells you | What it does not tell you |
|---|---|---|
| Visible in the user directory | The user exists in the environment | Whether the user is safely removable from billing now |
| Inactive or stale | Recent usage is weak or absent | Why the user still counts or what lane the row belongs in |
| Suspended or removed | Access may have been reduced or removed | Whether every related billing or review question is now resolved |
| In a default or access-granting group | There is still a structural path to access | Whether the business owner agrees the access should go |
| In a non-human or exception lane | The row probably needs different handling | Whether it belongs in the ordinary cleanup batch |
This is where many finance and admin conversations go sideways. People use the same row to answer different questions:
- "Does the user exist?"
- "Did they use the product?"
- "Do they still count?"
- "Can we safely change this now?"
Those are not interchangeable questions.
Why billable access gets confusing in real teams
The access path outlives the original reason
Someone joins a team, gets put into the right groups, and everything works. Months later, the business reason changes, but the access path does not. That is how ordinary operational drift becomes ongoing spend.
Default groups feel administrative, not financial
This is exactly why they are dangerous. They sound like infrastructure, so teams stop seeing them as active billing mechanisms. Atlassian explicitly notes that default groups can lead to unintended license consumption if not configured properly.
Inactivity is treated like a cleanup decision instead of an input
An inactivity report is useful. It is not a full answer. It tells you who deserves review. It does not automatically tell you why the row is still billable, who should approve cleanup, or what should be held out.
Admin and finance are often using different language
Admins talk about groups, access paths, and product roles. Finance talks about seat counts and savings. Billable-access cleanup becomes easier the moment those two views are connected cleanly.
What people usually miss
Users can count even if they did not log in
Atlassian's billing documentation states that users added to an app are counted toward billing even if they do not accept the invite or log in. That is an uncomfortable fact for teams that rely too heavily on activity as the whole model.
Default groups are not just convenience
They are part of the billing path. If they remain tied to people who no longer need the product, waste survives quietly.
Not every candidate row belongs in the same cleanup batch
Humans, exceptions, service accounts, and externally managed rows often need different treatment. A row can still be billable without being ready for ordinary cleanup.
Finance needs a stable explanation, not just a lower number
If the team cannot explain why the row counted, why it was changed, and what was held out, finance will keep reopening the same discussion next quarter.
A practical review framework
If your goal is to make billable access easier to reason about, use this sequence:
- start with the row that appears billable
- identify the access path that still makes it count
- classify the row:
- actionable human
- owner-review case
- non-human or exception
- externally managed
- decide whether the row belongs in this cleanup batch
- preserve enough proof that another reviewer can understand the decision later
That framework is more useful than a raw stale-user list because it turns the row into an action path, not just a spreadsheet observation.
Example: why inactivity is not enough
Suppose a user has not logged into Jira Software for 120 days.
That sounds like an easy cleanup candidate. But the review shows:
- the user still has product access through a default group
- the manager has not confirmed whether the contractor engagement actually ended
- the row is mixed into a batch that also contains service accounts
Now the right answer is not "remove the user because they are inactive."
The right answer is:
- confirm the billable access path
- classify the row correctly
- get the owner confirmation
- then act and preserve the proof
The inactivity was useful. It just was not the whole model.
When native admin tools are enough and when they are not
Native Atlassian screens are enough when:
- the question is small
- the row is obvious
- the same admin is making and documenting the decision
- nobody needs a durable proof record afterward
They become weaker when:
- many rows need to be split into different lanes
- finance wants a stable explanation
- held-out exceptions need to stay visible
- the same cleanup question keeps returning each cycle
That is the moment when the work shifts from visibility to governed review.
Where License Guard fits
That is exactly where License Guard becomes relevant.
Its value is not that it invents the idea of finding stale rows. Its value is that it helps teams trace the billable path, separate unlike rows into clearer lanes, keep approvals attached, and preserve proof after the cycle closes.
If this article made the billing model clearer and your next question is now "how do we actually run the cleanup review?", go next to:
What finance usually needs
Finance does not need the whole Jira access model.
It usually needs three things:
- why the row still counted
- why this row was actionable or held out
- where the proof of that decision lives afterward
The cleaner the team can explain those three points, the easier it becomes to turn access cleanup into believable savings instead of another seat-count argument.
FAQ
Does an inactive user always stop being billable?
No. Inactivity is one signal. A user can still count because the access path still exists through product-access configuration or group membership.
Do invited users count even if they never log in?
Atlassian's billing documentation says users added to an app are counted toward billing even if they do not accept the invite or log in.
Why do default groups matter so much?
Because they automate part of product access. If a stale access path survives there, the billing effect can survive quietly too.
When does a focused cleanup workflow become worth it?
When the problem is no longer just finding candidate rows. It becomes worth it when the team needs billable-path explanation, exception lanes, approval, and proof that survives the cycle.