What Maximum Quantity Billing (MQB) Means for Managing Inactive Atlassian Users

[#1]

In July 2025, Atlassian rolled out Maximum Quantity Billing (MQB) for monthly Cloud subscriptions. If you manage Jira, Confluence, or Jira Service Management licenses, this change directly affects how much you pay for inactive users -- and it makes the cost of delayed cleanup significantly higher than before.

This article explains what MQB actually changes, why it matters for teams with inactive users, and what practical steps you can take to avoid overpaying.

How Billing Worked Before MQB

Under the previous model, your monthly bill was calculated based on the number of users at the end of each billing cycle. If you added 15 users on the 3rd of the month and removed them on the 25th, your bill reflected only the users present at month-end. This gave admins a window to be reactive -- clean up users when convenient, and the bill would adjust.

What MQB Changes

Under Maximum Quantity Billing, Atlassian bills based on the highest number of users at any point during the billing period. If your user count peaked at 120 on the 5th but dropped to 105 by month-end, you pay for 120.

There are no mid-month credits. Users added at any point during the month count for the full month. The only way to reduce next month's bill is to have fewer users before the new billing cycle starts.

MQB applies to monthly subscriptions for Jira, Jira Service Management, Confluence, Jira Product Discovery, Compass, and Guard. Annual subscriptions are currently unaffected.

Why This Matters for Inactive Users

Before MQB, an admin could afford to be somewhat relaxed about user cleanup. A quarterly audit was usually good enough -- you would find inactive accounts, remove them, and the next month's bill would reflect the change.

Under MQB, every month that an inactive user stays on the roster costs you for the full month. There is no partial credit for removing them mid-cycle. The financial incentive has shifted from "clean up when you get around to it" to "keep your user count clean at all times."

For organizations with 10-30% inactive users (which is typical based on what we see across Atlassian Cloud customers), MQB turns a minor inefficiency into a meaningful line item. A company with 200 Jira users and 20% inactivity is paying for 40 users who contribute nothing -- every single month, at the peak count.

The Compounding Problem

Inactive users accumulate between cleanup cycles. If your team does quarterly audits, that is three months of growth in inactive accounts before each cleanup. Under MQB, each of those months bills at the peak, which includes all the accounts that should have been removed earlier.

This is why continuous, automated cleanup is more valuable under MQB than it was before. The ROI of automation increases directly with billing frequency and the speed at which inactive accounts accumulate.

Practical Steps to Manage Inactive Users Under MQB

1. Know Your Baseline

Before optimizing, understand where you stand. Go to admin.atlassian.com, export your user list, and filter by last active date. How many users have not logged in within 60, 90, or 120 days? That number multiplied by your per-user cost is what inactivity costs you each month under MQB.

2. Clean Up Before the Billing Cycle Resets

Under MQB, timing matters. If your billing cycle resets on the 1st of the month, do your user cleanup in the last week of the prior month. Any users removed before the new cycle starts will not count toward the next month's peak.

3. Separate Jira and Confluence

Jira and Confluence are billed separately with separate user counts. A user might be active in Jira daily but have not opened Confluence in six months. Check both products independently -- partial license reclamation (removing Confluence access while keeping Jira) is often the easiest win.

4. Consider Product Group Removal Instead of Deactivation

Deactivating a user removes them from all Atlassian products. Removing them from a specific product group (e.g., the confluence-users group) revokes access to just that product. Under MQB, the goal is to minimize the user count per product, so group removal gives you more granular control.

5. Automate the Cleanup

Manual cleanup works for small teams, but under MQB the penalty for delayed action is higher. Automation tools that monitor user activity and remove inactive accounts on a daily schedule ensure your user count stays clean continuously -- not just at quarterly review time.

Full disclosure: I work on User Management Automation for Jira & Confluence, which is one app in this category. It handles both deactivation and product group removal across Jira and Confluence, with configurable inactivity thresholds. There are other tools on the Marketplace that address this as well -- the important thing is to have something running continuously rather than relying on periodic manual audits.

The Bottom Line

MQB does not change the fact that inactive users cost money. What it changes is how quickly that cost accumulates and how much you lose by waiting to act. Under the old billing model, procrastination had a relatively low cost. Under MQB, every month of inaction is billed at peak -- and that peak includes every inactive account you have not yet cleaned up.

If you have been putting off a user audit, MQB is a good reason to move it up the priority list. And if you are already managing inactive users manually, it might be worth evaluating whether the cost of automation is less than the cost of the users it would catch between your manual cleanup cycles.

Happy to answer questions in the comments about MQB specifics or approaches to user cleanup.