Ask two people at the same company for last month's MRR and you can get two different answers from the same billing account. Neither is lying. One counted the annual prepay that came in on the 3rd as cash in that month; the other spread it over twelve. One left a customer in dunning inside the number; the other took them out at the first failed charge. The formula is not the problem. The decisions underneath it are.
What is the difference between MRR and ARR?
MRR (monthly recurring revenue) is the normalized monthly value of all active subscriptions. ARR (annual recurring revenue) is the same run rate expressed per year, usually MRR times 12. Both exclude one-time fees and services. MRR is the operating view you watch month to month; ARR is the annualized view boards and investors compare.
If you want to convert one into the other, or check a figure quickly, our MRR and ARR calculator does the arithmetic. The rest of this post is about what the arithmetic cannot do for you.
ARR is not booked revenue, and it is not a forecast. It is a snapshot of the recurring business as it stands today, scaled to a year. That is why it suits companies selling annual or multi-year contracts, where a monthly view feels noisy, and why early-stage companies on monthly plans tend to talk in MRR: it moves visibly when something changes. Both inherit the same assumptions.
The treatment decisions that decide the number
Every MRR figure is the output of a handful of choices, usually made once, often by whoever set up the first dashboard, and then forgotten. Two teams reading the same Stripe account can report different MRR because they made these choices differently. The fix is not a better tool. It is writing the choices down and applying them the same way every month.
| Situation | Common MRR treatment | What goes wrong if you skip the decision |
|---|---|---|
| Annual prepay | Divide the contract by 12 and count that each month | Counted as cash, MRR spikes in the invoice month and looks like churn for the next eleven |
| Mid-cycle upgrade | Count the new plan price from the change date; ignore the one-off proration charge | Proration lands as a strange one-month bump that reverses itself |
| Discount or coupon | Count the price actually charged; record when the discount expires | List price overstates MRR; an expiring coupon later shows up as "expansion" nobody earned |
| Free trial | Exclude until the first paid charge | Trials inflate MRR and their non-conversion reads as churn |
| Paused subscription | Remove while paused, return as reactivation | Paused accounts sit in MRR earning nothing, or vanish without a trace |
| Failed payment in dunning | Pick one: keep until the subscription cancels, or remove at first failure | Different people pick differently and the month-end number moves with whoever ran the report |
| Refund or credit | Leave MRR alone for a one-off goodwill credit; reduce it if the price itself changed | A single refund reads as contraction, or a real price cut never shows up |
| Usage charges | Exclude, or include only a committed minimum | A heavy usage month looks like expansion that disappears the month after |
| Multi-year deal | Normalize to the annual value, then to monthly | Booking three years as one year's ARR triples a customer on paper |
| One-time setup fee | Exclude | Services revenue inflates the run rate for one month |
A worked example, with round hypothetical numbers: a customer prepays $12,000 for a year on the 3rd of January. Normalized, that customer is $1,000 of MRR every month from January to December. Counted as cash, it is $12,000 of "MRR" in January and nothing for eleven months, which on a chart looks like a large new customer followed by immediate churn. Same customer, same contract, two stories.
No row has the only defensible answer. What matters is that the choice is written down, followed, and announced when it changes.
Our team doesn't see the revenue impact of their work, how do we change that?
Stop showing them the company total. A single MRR or ARR figure tells a product team almost nothing about their own work, because it is a sum of many accounts moving in different directions for different reasons. Nobody can say which part of a rise was theirs, or which part of a drop they could have prevented.
The useful view is the movement ledger by account. Every month, MRR changes for five reasons, and each one belongs to specific customers:
- New - accounts that started paying this month.
- Expansion - existing accounts paying more, through upgrades or added seats.
- Contraction - existing accounts paying less.
- Churn - accounts that stopped paying.
- Reactivation - accounts that had churned or paused and came back.
An illustrative month, again with hypothetical round numbers: start at $100,000 MRR, add $6,000 new, $4,000 expansion and $1,000 reactivation, subtract $2,000 contraction and $3,000 churn, and you end at $106,000. The total says "up 6%". The ledger says which accounts expanded, which ones left, and gives the team a list of names to look at.
That list is where product work connects to revenue. The expansion accounts: what did they ask for, and did you ship it before they upgraded? The churned accounts: what was sitting open in the backlog with their name on it? Answering that needs billing data and product data on the same customer record, which is the setup we walk through in connecting Stripe to product analytics. Once each request carries the MRR of the accounts behind it, you can rank the roadmap by revenue at stake instead of votes, and choose which of these numbers belong on the team's own scoreboard using the product metrics that actually matter.
The last step is closing the loop after shipping. In AIOProductOS, every shipped feature carries a verdict - adoption, MRR adopted and retention lift - on its task card, so the team sees what their release did for the accounts that used it. That lift is correlational, not proof of cause, and it should be read that way. It is still a far better signal than watching the company total and guessing.
Ask an AI assistant for your MRR, and make it show its work
Ask an assistant connected to your data "what is our MRR?" and you get a confident number back. With no stated treatment, it is one more figure that may or may not match the others. Ask in a way that forces the assumptions into the open:
"What was our MRR as of [date]? How many active subscriptions and accounts does it cover, how did you treat annual plans, discounts, trials, paused subscriptions and failed payments, and what were new, expansion, contraction, churn and reactivation for the month?"
A checkable answer includes all of these:
- An as-of date - MRR without a date cannot be compared to anything.
- The subscription and account count - so you can spot a missing segment immediately.
- The treatment of each item in the table above - stated, not implied.
- The movement breakdown - so the total can be traced to accounts.
Then verify it. Pull the same figure from your billing system's own reporting for the same date and compare. If the two differ, the gap should be explainable by a named treatment choice, such as "the assistant excluded accounts in dunning, the billing report kept them". A gap you cannot explain means one of the two numbers is wrong, and you should not use either until you know which.
If your billing data sits on account records an assistant can reach over MCP - in AIOProductOS, the Stripe connector lands each customer's plan, subscription status and MRR on the matching account, reading billing only and never changing your Stripe configuration - the same rule applies. The assistant's answer is a starting point that you check against the source, not the source itself.
When you need a dedicated subscription-metrics tool instead
Be clear about the job. If you need board-grade MRR and ARR reporting, cohort revenue analysis, revenue recognition, or numbers that feed a finance close, use your billing system's own reporting or a dedicated subscription analytics tool built for that work. Those tools exist to make the finance number authoritative, auditable and consistent across periods, and they are the right place for it.
AIOProductOS is not revenue operations software, and it is not trying to be your system of record for revenue. Revenue is on the record because prioritization needs it. Its role is narrower and different: putting each account's plan, subscription status and MRR next to the requests that account made and the work you shipped for it, so a product team can see which customers a decision affects. Keep the finance number where finance keeps it, and agree on the treatment rules so both views start from the same definitions.
Pick the rules, then pick the number
MRR versus ARR is the easy question: same run rate, two time scales, one-time revenue excluded from both. The questions that decide whether either number means anything come before the formula. Write down how you treat annual prepay, discounts, trials, pauses, dunning, refunds, usage and multi-year deals, apply it every month, and break the total into account-level movement so the people building the product can see their part of it.
To convert between the two and check your own figures against those rules, run them through the MRR and ARR calculator.