Why your Atlassian user count is wrong, and it's not headcount

The number everyone argues about first

The call usually starts the same way. Someone in IT has opened Atlassian Guard, looked at the licensed user count, compared it to the number of people the company employs, and found more of the first than the second. The first explanation is always the same too: we must be paying for people who left. Sometimes that's part of it. It is never the main thing.

The main thing is that the count was never built to match headcount in the first place. Guard counts identities that have access. Headcount counts people. The two only line up when there is a deliberate structure connecting them, and in most Atlassian estates we walk into, there isn't one.

What we actually find

Across the reconciliations we've done, the gap breaks down into the same handful of causes, in roughly this order of how often they show up.

1. Groups that don't map to anything

The directory has groups. The Atlassian site has groups. The apps have their own product access groups. Nobody designed them to line up, so a person can be in a directory group that grants Jira, a site group that grants Confluence, and a product group that was created by hand during a migration and grants both. Each path is a license. None of them is wrong on its own. Together, they mean there is no single place that says who should have access to what.

2. Attributes that never made the trip

Department, manager, employment status, cost center: the attributes that would let you scope access by rule are in the HR system and were never synced to the identity provider, or were synced once and never again. Without them, every access decision is made by group membership alone, and group membership is a list someone maintains by hand.

3. Sync into the wrong groups

SCIM provisioning is doing its job, and its job was configured to push everyone into a broad group. So every new hire lands in a group that grants every product. The count climbs with every joiner, and no leaver ever reduces it, because the leaver process removes the person from HR and not from the group.

4. Accounts that were deactivated but never deprovisioned

Deactivating a user in the identity provider is not the same as removing their access in Atlassian. If the connection was set up to create but not to suspend, a deactivated person keeps their site access and their license until someone notices. We routinely find users who left months ago, are marked inactive in the directory, and can still log in to Jira.

5. Duplicates from mergers and acquisitions

Two companies, two directories, two Atlassian sites, one migration. The same person now exists twice: once under each email domain, sometimes three times if a personal Atlassian account was ever invited. Every copy is a license. Every copy is also a permission set nobody is reviewing.

6. People who have access and shouldn't

Contractors whose engagement ended. Vendors given a project role for one integration. Service accounts created for a script that no longer runs. These are the accounts that make the count wrong and the audit uncomfortable, because the question isn't "why are we paying for this" but "who has been able to read this."

How we find it

We don't start with the count. We start with the structure. The first artifact is a map: every group in the directory, every group on the site, every product access group, and what each one grants. Then we pull the user list from Guard and the user list from the identity provider and join them on email. What falls out of the join is the reconciliation: accounts with no directory match, directory users with no Atlassian match, people in more groups than their role explains, and deactivated users who still resolve to an active Atlassian account.

Two exports and a join sound simple. The reason it isn't is that every mismatch has a story, and the story is usually a decision nobody wrote down. That's the part the customer has to own.

What the fix looks like

1. A group model. A small number of groups, named for what they grant, mapped one-to-one to product access. Directory groups feed them. Site groups and hand-made product groups are retired. This is the decision that has to be made before anything else, and it's the one that takes the longest, because it forces the question of who should have what.
2. Everyone in scope. Every account that should exist is provisioned by the same path, with the same attributes. Accounts outside that path are either brought in or removed. No exceptions list.
3. Deprovisioning that actually removes access. Deactivation in the identity provider suspends the Atlassian account the same day. This is a configuration change and a test, and it's the single highest-value fix on the list.
4. Duplicate cleanup. Merged accounts, one identity per person, with the history preserved.
5. Permission review. Once the groups are right, the permission schemes are simplified against them. Most estates lose half their project permission entries here and nobody notices anything except that the admin screen got shorter.
6. A recurring access review. Quarterly, owned by someone, with the join from step one run again. The count matches headcount because the structure makes it match, not because someone reconciled it by hand.

Why this matters more now

Every one of the accounts above is an identity that can be given to an agent. Rovo, Forge apps, and MCP connections act as a user or through a user. If your human identities are a list nobody can explain, your agent identities will be too, only faster. The group model you build to fix the count is the same model that decides what an agent can touch. That's why we treat a user count that doesn't match as the start of the identity work, not as a licensing problem.