Expansion revenue: how to measure expansion MRR and grow it four ways
Expansion MRR is the extra monthly revenue from existing customers. How to calculate it, a worked example, four ways to grow it, and how to report it.
In short: Expansion revenue is the extra recurring revenue you earn from customers you already have, and expansion MRR is that figure for one month, calculated by adding up every increase in monthly revenue from merchants who were already paying at the start of the month, leaving out new installs and returning customers. It grows in four ways, usage growth, tier upgrades, add-ons and cross-sell, and each of those lives in a specific place inside the product. Report it monthly, split by source and by the screen that produced it.
What is expansion MRR?
Expansion MRR is the increase in monthly recurring revenue that comes from existing customers paying you more. A merchant on your $49 plan moves to $99, and the $50 difference is expansion MRR. A merchant on a usage plan tracks more affiliate sales and crosses into a higher band, and the difference is expansion MRR. Nothing from a merchant who installed this month counts.
ChartMogul's help centre defines the MRR movements the way most billing tools do. When a customer's overall MRR increases, that is expansion. When they downgrade, or cancel some but not all of their subscriptions, that is contraction. Cancelling the last subscription is churn. A churned customer who comes back is reactivation, not expansion. One detail worth copying: an expiring discount counts as expansion, and applying one counts as contraction.
Expansion is one of the three inputs to net revenue retention. NRR is the annual, cohort-level view the board reads. Expansion MRR is the monthly line a product team can act on, because you can see which merchants moved and which screen they were on when they did.
How do you calculate expansion MRR?
Take every merchant who was paying at the start of the month. For each one, compare what they pay at the end of the month with what they paid at the start. Add up the increases. That sum is expansion MRR. The decreases, summed separately, are contraction.
Expansion rate is expansion MRR divided by total MRR at the start of the month.
A worked example for a Shopify app. On 1 September you have 800 paying merchants and $64,000 MRR. Among those 800, during September:
| Movement | Merchants | MRR effect |
|---|---|---|
| Grew usage into a higher band | 45 | plus $2,700 |
| Upgraded to a higher tier | 18 | plus $1,800 |
| Bought an add-on | 12 | plus $480 |
| Bought a second product | 9 | plus $630 |
| Downgraded a tier | 30 | minus $1,500 |
| Uninstalled or cancelled | 32 | minus $2,240 |
Expansion MRR = $2,700 + $1,800 + $480 + $630 = $5,610. Expansion rate = $5,610 / $64,000 = 8.8%.
Contraction MRR = $1,500. Churned MRR = $2,240.
Also in September, 60 new merchants started paying ($4,200) and 5 merchants who had churned came back ($300). Neither is expansion. Net new MRR for the month is $4,200 + $5,610 + $300 minus $1,500 minus $2,240 = $6,370, and you end the month at $70,370.
Two rules keep the number honest. Measure each merchant's net change, so a merchant who upgrades and then removes an add-on in the same month shows up once, at their net figure. And when the price list changes, label the resulting increase as a price increase, not as a product win. SaaS Capital's 2025 retention benchmarks note that NRR includes upsells, new product cross-sells and price increases, which is exactly why you want them on separate lines.
What are the four ways to grow expansion revenue?
Every expansion event is one of four things. Each one has a trigger, and each trigger has a home inside the product.
| Way | What happens | Where it lives in the product |
|---|---|---|
| Usage growth | The merchant's volume crosses into a higher band | The usage meter on the home page, and the warning before the band changes |
| Tier upgrade | The merchant chooses a higher plan for a feature or a limit | Locked feature empty states, limit warnings, the moment after a result |
| Add-on | The merchant buys one extra thing not everyone needs | The settings page where the need appears, and the plan picker |
| Cross-sell | The merchant buys a second product from you | The home page, and empty states the second product would fill |
Usage growth is the only one of the four where the merchant does not have to decide anything. A brand that tracked $20,000 in affiliate sales in August and $35,000 in September pays more in September, and the extra revenue arrives with no sales conversation. The product work is to make the unit something the merchant is glad to see grow, and to show the meter every day so the bill is never a surprise. I cover choosing the unit and the tiers in usage-based pricing.
Tier upgrades need a decision, so they need a moment. The upgrade prompt belongs where the merchant is already thinking about what the next tier does: the greyed-out automation tab they just clicked, the "40 invites left" warning, the notification of a first affiliate sale. The placement, cohort and copy of those prompts are the subject of in-app upsell design.
Add-ons are for things a minority of merchants need a lot of: extra team seats, SMS credits, a second storefront, a white-label affiliate portal. An add-on keeps the main tiers simple while letting the merchants who need the extra thing pay for it. The trigger is the moment the need shows up, which is usually a settings page or an error ("this store is already connected to another account").
Cross-sell is a second product billed on its own. An affiliate app that adds a reviews product. A creator outreach tool that adds sample management. It is the hardest of the four because the merchant has to be convinced of a second thing, but it is also the one that adds the most MRR per event. One constraint for Shopify apps: the App Store requirements say a listing should describe the app's features and not reference your other apps or services, so cross-sell has to happen inside the product, not on the listing.
What do the benchmarks say about expansion?
Less than you would like. The surveys I trust publish NRR, not a standalone expansion rate, so I will not give you a median expansion rate.
What they do show is how much pricing structure matters. Aleph's summary of the 2026 Aleph x Benchmarkit report, built on full-year 2025 data from 342 SaaS and AI-native companies (230 of which reported NRR), puts the median NRR at 102%. Within that, it reports usage-based companies at a median NRR of 108% against 98% for seat-based, and says the 75th percentile for usage-based models reaches 155%. The same summary states that expanding a customer costs about half what acquiring one does, $0.80 against $1.63 per dollar of new ARR.
SaaS Capital's 2025 survey, its 14th, with more than 1,000 private B2B SaaS companies responding, found a median NRR of 101% and median GRR of 91%. Its growth chart shows that moving NRR from the 100% to 110% band into the 110% to 120% band came with a 9 point higher median growth rate, and it says plainly that the relationship between gross retention and growth is not as direct. Growth follows expansion.
Caveats. Both are self-reported surveys. Neither is specific to e-commerce apps, where contracts are small and month-to-month, and where a merchant's own revenue swings with the season. If your pricing follows the merchant's volume, your expansion line will be high in November and low in February, and a monthly report that ignores that will send you chasing ghosts.
How should you report expansion MRR each month?
One page, same layout every month, read by product and customer success together. Mine would have four blocks.
- The five movements. New, expansion, contraction, churn and reactivation, each as a dollar amount and a merchant count. Net new MRR at the bottom. If you only report expansion, a bad contraction month hides behind a good expansion month.
- Expansion by source. Usage growth, tier upgrades, add-ons, cross-sell, and a separate line for price increases. This is the block that tells you which of the four ways is working. An app that gets all its expansion from usage growth has no upsell problem, it has a pricing model. An app that gets none from usage growth probably has the wrong unit.
- Expansion by surface. Tag every upgrade prompt, limit warning and plan picker with where it was, and record the plan change as a backend event with that tag attached. Then you can say "the post-result prompt produced 11 upgrades, the banner produced 2" and remove the banner.
- Expansion by health band. If you have a customer health score, split expansion by band. Expansion from healthy merchants is the kind that stays. Expansion from merchants who then downgrade in Q1 is the kind you should stop counting on.
Two checks I would run on the page before trusting it. First, are the same merchants on the expansion line and the contraction line a few months apart? That is a usage band they were pushed into and resented. Second, is any expansion coming from merchants with an open support ticket or a failed payment? When I led a customer success team, that is the kind of upgrade I would least want to see. My guess is that it is a merchant trying to make something work by paying for it, and that it tends to come back as a refund request.
Where to start
- Pull last month's billing events and classify every change for existing merchants as expansion, contraction, churn or reactivation. Write down expansion MRR and expansion rate.
- Split the expansion line four ways: usage growth, tier upgrade, add-on, cross-sell. The empty rows tell you which way you have not built yet.
- Find the one screen in your product where each of your non-empty rows is produced, and tag it so next month's report can attribute by surface.
- Compare the expansion line to the same month last year before reacting to it, especially if your pricing follows merchant volume.
- Put the page in front of product and customer success together, once a month, and pick one source to improve for the next 90 days.
Frequently asked questions
What is the difference between expansion MRR and net revenue retention?
Expansion MRR is the monthly increase in recurring revenue from existing customers, on its own. Net revenue retention combines expansion with contraction and churn over a year and expresses the result as a percentage of the starting cohort's revenue. Expansion is one input to NRR.
Does expansion MRR include new customers or reactivations?
No. Expansion MRR only counts increases from customers who were already paying at the start of the period. New customers are new MRR, and customers who churned and came back are reactivation MRR. Both are reported on their own lines.
What is a good expansion rate for a SaaS company?
The surveys I have checked publish net revenue retention rather than a standalone expansion rate, so I do not have a verified median to give. What they do show is that usage-based companies report a median NRR of 108% against 98% for seat-based in the Aleph x Benchmarkit data on full-year 2025, which is mostly an expansion effect.
How is expansion MRR calculated?
For every customer paying at the start of the month, subtract their starting MRR from their ending MRR and add up the positive differences. Divide by total MRR at the start of the month to get the expansion rate.