Summary

  • Removing users during a maximum-quantity monthly billing period leaves its billed quantity intact. Those paid, vacant seats can be reassigned within the period.
  • Using Atlassian’s illustrative $18 price and 25 remaining days, adding three users before removing three produces a $45 incremental charge. Removing first keeps the comparison scenario within its original ten seats.

Two administrators can finish with the same ten names and leave different bills behind. One removes three old app users before adding their replacements. The other adds the replacements first. For a paid monthly Atlassian app subject to maximum quantity billing, the second administrator can buy three extra seats without increasing the final headcount by one.

The expensive event is the passage through thirteen. A month-end staffing report has no reason to remember it. The billing system does.

A vacancy is an asset already bought

Atlassian’s maximum quantity billing instructions raise the billed quantity when added users take the subscription above its existing quantity. The extra users incur prorated charges for the remaining period, added to the next bill. Removing users later does not reduce that period’s charge. It leaves spare, paid seats available for someone else.

Consider one covered paid monthly app starting with ten users. On day five, three genuine removals and three new grants of access are required. Remove first: the count falls to seven, then returns to ten. Add first: it rises to thirteen, then returns to ten. Only the second path crosses the paid boundary, and its billed quantity stays at thirteen for the current period.

For scale, use the $18 per-user monthly rate in Atlassian’s explanatory examples. That is an illustrative price, not a current Jira quote. Assume a 30-day period with 25 days remaining. The extra three seats cost 3 × $18 × 25 ÷ 30, or $45. The first path creates no incremental seat charge for this exchange. This is our conditional calculation from the rules, not an observed customer invoice.

The prorating matters. Thirteen full monthly fees are not being imposed retrospectively. Nor should the official Melissa example’s $279 estimate be used as the opposite side of this comparison. Melissa ends with thirteen users: her next estimate combines a $234 base for the coming month with $45 for the previous period’s additions. Both replacement paths here end with ten. Comparing the whole $279 with $180 would smuggle a different next-month workforce into a question about ordering.

The seat can arrive before its occupant

The user-management documentation says users added to an app count towards monthly subscriptions even if they have not accepted their invitation or ever logged in. Access can become billable before its recipient turns up on an activity report.

That separates three records which buyers often want to collapse into one: access granted, activity observed and quantity already billed. A last-login report answers an activity question. It does not tell the buyer how much paid capacity remains, or erase a peak created when access was opened. Nor does an absent login establish anything about an individual’s productivity.

The relevant event is addition to the app with its access rights. Merely sending an arbitrary invitation email is insufficient evidence of a new charge. The next question is whether the grant fits inside spare capacity already paid for. An unused paid seat and an unpurchased seat may look equally empty; financially, they are very different chairs.

When a help-desk queue becomes a purchasing desk

Atlassian’s 2025 announcement promoted predictability and simpler tracking. The current instructions list the affected monthly subscriptions for Compass, Confluence, Atlassian Guard, Jira, Jira Product Discovery, Jira Service Management, Loom and Marketplace apps. Its licensing FAQ distinguishes the monthly maximum from annual user tiers. This is an examination of an existing monthly mechanism, with no need to dress it up as a fresh 2026 price rise.

For the seller, additional access capacity was available during the period and retains its price. For the buyer, opening permissions feels like administration rather than procurement. A manager asks for a prompt start, an administrator supplies it, and another queue handles the old permissions. The invoice collects the timing differences between them. Nobody needs to hire an extra person, or mishandle a ticket, for those differences to cost money.

The peak has an expiry boundary. The final day’s user count sets the next month’s starting billed quantity. In Atlassian’s Armando example, ten users fall to seven: ten seats remain paid in the current period, three are available for reuse, and the next month starts at seven. A historical maximum does not perpetuate itself indefinitely.

A real invoice requires the actual product and plan’s pricing schedule, cycle dates, existing billed quantity and access-change history. The commercial implication is already plain: equal ending headcount does not guarantee equal cost. A handover requiring overlapping access can be worth buying. Overlap created solely by the order of two tickets is still a purchase. The company should at least know who placed it.