Add Your MRR Movements to the Stripe Dashboard

What “MRR movements” actually means (and why your board cares)

Monthly Recurring Revenue (MRR) is your recurring revenue normalized into a monthly amount. If you sell annual plans, you translate them into a monthly equivalent so you can compare month to month without playing mental gymnastics.

The Big 5 MRR movements

• New MRR: revenue from customers who become paying subscribers for the first time in the period.
• Expansion MRR: additional recurring revenue from existing subscribers (upgrades, more seats, add-ons, higher tiers).
• Contraction MRR: recurring revenue lost from existing subscribers (downgrades, fewer seats, removing add-ons).
• Churn MRR: recurring revenue lost when subscribers cancel (or become unpaid and stop counting as active recurring revenue).
• Reactivation MRR: recurring revenue regained when previously churned subscribers return.

Put those together and you get the number operators love because it explains the “why” behind the line going up or down:

Net New MRR = New + Expansion + Reactivation − Contraction − Churn

If you only track total MRR, you’ll miss the difference between “we grew because our product is sticky” and “we grew because we’re sprinting uphill while churn is chasing us with a baseball bat.”

What Stripe already gives you (yes, right now) in Billing Analytics

If you’re on Stripe Billing, Stripe’s Dashboard includes subscription analytics that cover MRR and how it changes over time. In other words: Stripe isn’t just a payment processor here; it can be your subscription telemetry.

1) Stripe Billing Analytics + “Explore” drilldowns

Inside the Dashboard, Stripe Billing’s analytics let you monitor recurring revenue, audit changes, and drill into what drove a metric. The most practical workflow looks like this:

1. Open the Stripe Dashboard.
2. Go to Billing → Analytics.
3. Find charts like MRR, MRR growth, and churn-related views.
4. Click Explore to open the chart with a table underneath for deeper inspection.
5. Drill into the underlying events to see which customers expanded, downgraded, churned, or reactivated.

This is the fastest way to “add” MRR movements to your Stripe workflowbecause it’s already there. You’re not building anything; you’re simply using the view that tells you what moved and who moved it.

2) Downloadable reports (aka: your roll-forward without tears)

If you want movement data you can model, reconcile, or pipe into internal reporting, Stripe offers downloadable CSV reports such as:

• MRR per subscriber per month: month-end MRR per subscriber.
• Subscription metrics summary: a roll-forward-style summary (MRR roll-forward, subscriber roll-forward, and more).
• Customer MRR changes: a log of MRR changes (new, upgrades, downgrades, reactivations, churn).

That last onecustomer MRR changesis basically “MRR movements” in a file. If you’ve ever tried to rebuild it from scratch using events and invoices, you already know: it’s doable, but it’s also a hobby you did not consent to.

3) Configure how Stripe defines your metrics (don’t skip this)

This part matters more than most teams expect. Stripe lets you configure how it calculates metrics like MRR and churn. For example:

• Discount handling: you can choose whether to subtract discounts (recurring and/or one-time) in MRR calculations. That decision can meaningfully change movement attribution.
• When a subscriber counts as active: at subscription start vs. when the first payment is received. That affects “new” vs. “trial-to-paid” timing and can shift movement month boundaries.

Translation: before you add a fancy movement chart anywhere, decide what “MRR” means in your business and make it consistent. Your future self (and your finance person) will send you a thank-you note, possibly with snacks.

How to add MRR movements to the Stripe Dashboard (3 practical approaches)

“Add to the dashboard” can mean different things depending on your team’s workflow. Here are three waysfrom zero-code to “we built a mini product inside Stripe.”

Approach A: Make Billing Analytics your default revenue cockpit (no code)

If your goal is visibility and shared truth, start here. Stripe Billing Analytics already includes MRR and movement-aware views like MRR growth, plus drilldowns. To operationalize it:

• Set a weekly ritual: open MRR growth, click Explore, scan top expansions and top churn.
• Create a “movement review” checklist: 10 minutes, same filters every time (product, price, segment).
• Export the Customer MRR changes report monthly: store it with your month-end close artifacts.

This approach is surprisingly effective because it keeps analysis close to billing reality. You’re not arguing with “a dashboard” anymore; you’re looking at the system of record where subscriptions live.

Approach B: Use Stripe Sigma to create a custom MRR movement report inside the Dashboard

If you want movements broken down by your exact definitions (plan families, regions, sales-assisted vs. self-serve, metadata tags), Stripe Sigma is the “power tool” option. Sigma lets you query Stripe data with SQL inside the Stripe Dashboard and turn results into charts.

A practical Sigma strategy for MRR movements is: start from subscription change events, then roll them up into monthly movement buckets. Stripe even provides Stripe-data tables designed to represent subscription item change events (including MRR impact per event).

Step-by-step: a clean, board-friendly MRR roll-forward in Sigma

1. Open Sigma from within the Stripe Dashboard.
2. Start with a template related to subscriptions/billing, then adapt it to your needs.
3. Aggregate changes by customer and day (or month) to avoid double-counting multiple events for the same customer.
4. Classify movements by comparing current MRR to previous MRR:
   • 0 → positive MRR (first time): New MRR
   • 0 → positive MRR (not first time): Reactivation
   • positive → higher positive: Expansion
   • positive → lower positive: Contraction
   • positive → 0: Churn
5. Roll up by month and present a roll-forward: Beginning MRR + New + Reactivation + Expansion − Contraction − Churn = Ending MRR.
6. Visualize it as a stacked bar (movements) plus a line (ending MRR), then share the report with your team.

Here’s an illustrative (simplified) SQL pattern you can adapt. Table names and fields vary by Stripe Data setup, but the logic stays the same: use MRR deltas, then bucket them into movements.

Note: the example above intentionally keeps “New vs. Reactivation” simple. In practice, you’ll want to detect whether it’s a customer’s first-ever positive MRR (New) or a return after a previous churn (Reactivation). Stripe’s recommended approach is to track the count of meaningful MRR changes over time and use that to differentiate first-time starts vs. restarts.

When Sigma is the right move

• You need movement reporting by segment (product line, region, sales channel, customer tier, metadata tags).
• You want to reconcile movement totals against your internal metrics definition.
• You want a report that stays inside Stripe and doesn’t require a separate BI tool for basic questions.

Approach C: Build a Stripe App that embeds MRR movements directly into the Dashboard UI

If you want the most “native” experiencewhere a teammate clicks into a customer in Stripe and instantly sees their MRR movement history Stripe Apps is how you do it.

Stripe Apps lets you embed custom UI directly inside the Stripe Dashboard. That means you can create a panel like: “MRR movement timeline (last 6 months)” on the Customer page, or a dedicated internal “MRR Movements” app view.

What a useful internal MRR Movements app can show

• Customer-level movement ledger: upgrade/downgrade/churn/reactivation events with timestamps and amounts.
• Plan mix context: which prices drove expansion vs. which prices were churn-heavy.
• Ops flags: “payment failed” vs. “customer canceled” vs. “discount expired” (so you don’t treat everything like a product problem).
• One-click links: jump to subscription details, invoices, or payment history.

This is especially valuable if you have a RevOps or Support team living in Stripe all day. Instead of sending them out to a BI dashboard, you bring the insight to the place where action happens.

Specific example: an MRR roll-forward you can explain in one breath

Let’s say you start April with $50,000 MRR. During April:

• New MRR: +$6,000 (new customers came in)
• Expansion MRR: +$4,500 (upgrades and add-ons)
• Contraction MRR: −$1,200 (downgrades)
• Churn MRR: −$3,800 (cancellations/unpaid)
• Reactivation MRR: +$700 (customers returning)

Your net change is: 6,000 + 4,500 − 1,200 − 3,800 + 700 = +$6,200. Ending MRR becomes $56,200.

That one breakdown answers five follow-up questions automatically: Is growth acquisition-led? Is expansion strong? Are downgrades climbing? Is churn spiking? Are win-back campaigns working?

Common gotchas that make MRR movements lie to you

Annual plans and normalization

If you sell annual subscriptions, normalize to monthly (e.g., $600/year becomes $50/month) so movements reflect recurring value, not billing cadence. Stripe’s examples and definitions treat annual plans this way in MRR reporting.

Discounts: decide whether you want “list MRR” or “net MRR”

Teams love to say “we’re at $80k MRR” and then quietly forget $18k of that is a long-running discount that never ends. Stripe supports configurable discount handling so your MRR can reflect either sticker price or the more conservative “what we actually collect” version.

Trials, delinquency, and what counts as churn

Trials typically don’t count toward MRR until they become paid. Likewise, what happens when a subscription becomes unpaid matters: movement reporting should consistently treat when a subscription stops contributing to MRR as churn.

Proration and mid-cycle changes

Upgrades and downgrades mid-cycle can trigger prorations and multiple events. If you aggregate naively, you can double-count movement. That’s why event-based movement tables and careful rollups (customer/day → month) are so important.

Multi-currency and FX adjustments

If you charge in multiple currencies, movements can shift due to exchange rate changes. A customer might pay the same amount in their currency, but your “home currency” MRR moves anyway. Treat FX separately so you don’t blame churn for what’s actually currency math.

Conclusion: keep your MRR story where your money lives

Adding MRR movements to the Stripe Dashboard isn’t about making another pretty chart. It’s about putting the “why” next to the “what,” so you can make decisions faster and argue less.

If you want the simplest path: use Stripe Billing Analytics, drill into MRR growth with Explore, and export the Customer MRR changes report for your month-end. If you want custom segmentation and deeper control: build a movement roll-forward with Stripe Sigma and visualize it inside Stripe. If you want it to feel truly native for your team: build a Stripe App that embeds movement insights directly on the pages your team already uses.

Your MRR number is your heartbeat. Your MRR movements are your diagnosis. Put them in the dashboard, and you don’t just know you’re alive you know what to fix before you start sweating through your hoodie.

Field Notes: of Real-World “MRR Movements” Experience

The first time most teams try to “add MRR movements to the Stripe Dashboard,” they don’t start with datathey start with a feeling. It usually sounds like: “Our MRR is up, but… it doesn’t feel up.” That’s the moment you realize total MRR is a single number trying to summarize five different forces that all pull in different directions. And if you’ve got discounts, annual plans, proration, and a handful of enterprise customers who upgrade whenever Mercury is in retrograde, the story gets messy fast.

One of the most useful habits I’ve seen is a weekly “movement review” where the team looks at MRR growth and immediately breaks it into: new, expansion, contraction, churn, reactivation. The ritual is boring on purpose. Boring means repeatable. Repeatable means you can detect patterns. For example, a few weeks of rising contraction might not move total MRR much if expansion is still strongbut it’s an early warning sign that something in your packaging or value delivery is slipping. Catch it early and you adjust pricing tiers, improve onboarding, or refine limits before it becomes a churn story.

Another surprisingly common lesson: you have to pick your definition of MRR and defend it like it’s your house in a zombie movie. Some teams want “list-price MRR” because it tracks product value; other teams want “net MRR” because it matches cash reality. Stripe’s metric configuration (especially around discount treatment and when someone counts as active) is where you make that decision official. If you don’t, you’ll end up with two dashboards, three definitions, and exactly zero trust in any of them.

When teams graduate from default analytics to Sigma, the biggest breakthrough is switching from “subscription objects” thinking to “movement events” thinking. Movement events are what let you build a clean roll-forward: beginning MRR plus/minus movements equals ending MRR. The first time you present that roll-forward and nobody asks “wait… where did the number come from?” is deeply satisfying. It’s like your metrics stopped being vibes and started being math.

Finally, if you build a Stripe App UI extension, keep it ruthlessly practical. Don’t build a museum exhibit of KPIs. Build a decision panel: last 10 movement events, what changed, by how much, and why (upgrade, downgrade, cancel, unpaid). Give your team the ability to click straight to the subscription and invoice context. When movement insights live in the same place as the billing truth, teams move fasterbecause the dashboard isn’t just reporting. It’s guiding action.