Run rate: what it is, how to calculate it and the difference from ARR

Run rate is an annualized revenue projection built from a recent period. The idea is simple: you take the current pace of the business, for example one month or one quarter of revenue, and stretch it to twelve months as if that pace would stay constant. The result is a quick estimate of how much the company would earn in a year if nothing changed.

It is an extrapolated snapshot, not a contracted number. That is why run rate works well for an instant read of the scale of the business, but it carries a strong assumption: that the period used is representative. In a SaaS, the most common version starts from MRR multiplied by 12.

The calculation is a direct extrapolation: pick a recent period, measure its revenue and multiply by the factor that turns it into a year.

• From the month: run rate = month revenue x 12.
• From the quarter: run rate = quarter revenue x 4.
• From MRR: in SaaS, run rate = MRR x 12.

Example: if last month closed at $80k of revenue, the annual run rate is $960k. The shorter the period used, the more sensitive the number is to one-off swings, so the choice of window matters as much as the math itself.

Run rate and ARR can land on similar numbers, but they start from different bases. A well-built ARR sums only the contracted recurring revenue of active subscriptions. Run rate annualizes a recent result, which may include one-off charges, ad hoc services or a seasonal spike.

• ARR: starts from what is recurring and contracted.
• Run rate: starts from what happened in a period, recurring or not.

When the period used in the run rate contains only clean recurring revenue, the two coincide. The gap appears precisely when the month had something that will not repeat, and then run rate inflates while ARR stays faithful to recurrence.

Confusing run rate with recurring revenue is one of the most common mistakes. Recurring revenue is what the customer pays repeatedly and predictably for the subscription. Run rate is only an annualized projection, which may or may not be built from recurring revenue.

If you annualize a month made only of subscriptions, run rate reflects recurring revenue. If you annualize a month that also had an expensive one-time implementation, run rate mixes the recurring with the one-off and stops being a good measure of predictable revenue. Rebuilding the number from MRR movements helps separate what is recurring from what is noise.

Run rate is only as good as the period it starts from. Because it assumes the current pace holds, any distortion in that period is multiplied by twelve and becomes a misleading projection.

• Seasonality: annualizing a peak month (or a trough) projects the whole year at the wrong pace.
• One-off charges: a single large sale inflates run rate as if it were recurring.
• Recent changes: high churn or a new launch do not yet show up in a single month.

That is why run rate is more reliable in stable, mature businesses, and more treacherous in young, seasonal or fast-changing companies. In those cases, it says more about the recent past than about the future.

Used carefully, run rate is a useful tool for quick reads and communication. It gives an immediate sense of scale, helps compare periods and serves as a base for targets, as long as everyone knows it is an extrapolation, not a guarantee.

The best practice is to annualize only clean recurring revenue, choose a representative period and revisit the number whenever the business changes pace. The market it tries to project is huge: according to Gartner, worldwide spending on SaaS applications is set to approach $300 billion in 2025. And because run rate depends on revenue holding up, it only holds true when retention keeps the base, something the private SaaS survey by KeyBanc Capital Markets shows with net revenue retention above 100%.