Every billable account should trace to a person or an owner.
Atlassian Cloud bills for every user with app access, whether or not they log in, and Atlassian Guard Standard bills each managed account or external user with access to a supported app once, across apps such as Jira, Confluence, and Trello, unless their plan already includes Guard Standard. That is why the Guard count drifts above headcount: leavers never deactivated in Atlassian, managed accounts in free Trello workspaces, contractors, integration users on human accounts, and duplicates all count. Atlas Bench, an Atlassian Platinum Solution Partner, reconciles every billable account against HR and identity provider records using last active dates from Atlassian Administration, deactivates or removes access nobody needs, and fixes the groups and SCIM provisioning that produced the gap.
We match your Atlassian billable users to headcount, account by account, and remove the access nobody needs. Then we fix the groups and provisioning that created the gap, so the count stays matched.
The problem
The question usually starts with a number. Someone compares the user count in Atlassian Administration, or the Atlassian Guard bill, with headcount and finds more accounts than people. The billing rules explain part of it. Atlassian counts a user once app access is granted, whether or not they accept the invitation or ever log in. People who join through an approved domain become licensed users. Guard Standard counts each managed account and external user with access to a supported app, including managed accounts in free Trello workspaces.
The rest comes from structure. Directory groups map to nothing, or to everything. Attributes that group rules depend on never synced. SCIM pushes everyone into a broad group that carries app access. Leavers are deactivated in the identity provider but never deprovisioned in Atlassian. Acquisitions bring duplicate accounts, and contractors and integrations run on human licenses with no owner. Removing inactive users by hand lowers the count once. It climbs back unless the groups and provisioning underneath change.
What the work is
Billable user export
Users, managed accounts, and external users exported from Atlassian Administration, with the last date each one was seen in each app and whether they are billable for Guard. The user counts page shows trends, but Atlassian says it is not a billing metric, so we work from the exports.
Headcount match
Every billable account matched to an HR record, a contractor agreement, or a named owner. Anything that does not match goes on an exceptions list with a cause and a proposed action.
Group and provisioning review
Groups traced to the app roles they grant, including default groups and the groups your identity provider pushes through SCIM. Broad groups that license everyone are narrowed in the identity provider, and approved domain and invite settings are checked, so access follows the job.
Account actions
For each exception, the smallest fix that works: remove access to one app, suspend, or deactivate the managed account. Deactivation stops billing, keeps the person's content, and can be reversed. Synced users are changed in the identity provider.
Service and integration accounts
Integration users on human licenses moved to Atlassian service accounts, which are not charged against your Jira or Confluence plan. Every organization gets five, and Guard Standard raises the limit to 250. Each one gets an owner.
Guard coverage
Authentication and external user policies reviewed so Guard covers everyone who needs its controls. A non-billable policy removes users from the Guard bill and from controls such as single sign-on enforcement, so we use it only where that trade is deliberate.
How it runs
-
Export and match
1 weekBillable users exported with last active dates, matched against HR and identity provider records, and every gap labeled with its cause.
-
Clean up
1 to 2 weeksAccount actions approved by owners and applied, integration users moved to service accounts, and broad groups narrowed in the identity provider.
-
Keep it matched
1 weekDefault groups, app access settings, and provisioning rules set so new accounts follow the group model. Your team gets a monthly check and the runbook.
What you get
- A reconciliation of every billable account to a person, a contract, or a named owner
- An exceptions list showing the cause, the action taken, and who approved it for each account
- Inactive, duplicate, and departed accounts deactivated, suspended, or removed from apps, with synced users changed in your identity provider
- Integration users moved to Atlassian service accounts, each with an owner
- A group model mapping each identity provider group to the app roles it grants
- A monthly check built on Atlassian Administration exports and Guard insights