ARR, annual recurring revenue, is the annualised recurring revenue from active subscriptions. The metric answers a single question: how much revenue does the current customer base generate over the next twelve months if nothing changes?
What counts and what does not
The core of the definition lies in the word recurring. Subscription fees and contractually committed recurring services belong in it. Setup fees, training, consulting days, migration projects and anything else that occurs once do not. That boundary looks pedantic and is the actual purpose of the metric: an ARR containing project revenue no longer says anything about the reliability of the revenue base.
The relationship to MRR
ARR and MRR describe the same thing from two angles; arithmetically ARR is simply twelve times MRR. Which is used follows the business model. Products billed monthly with frequent movement in the base usually report MRR, because a monthly view captures the movement better. Products on annual contracts report ARR, because splitting them monthly implies a precision that does not exist.
The movement components
The ARR level alone says little. It becomes informative only when broken into its movements: new customers, expansion of existing contracts, downgrades and cancellations. Two companies with identical ARR growth can be in completely different positions — one grows out of its base, the other replaces with new customers what it loses to churn. Only the second view shows whether the product holds.
Common errors
Three errors make the figure useless. First, including one-off revenue, as described. Second, annualising a particularly good month — ARR represents the base, not the best run. Third, including contracts signed but not yet started; those belong in a separate figure, not in the running base.
Why the boundary matters commercially
In financing and sale processes, ARR is verified rather than believed. A figure containing project revenue or signed intentions gets found in diligence and damages the credibility of every other number with it. Anyone keeping the boundary clean from the start has no correction to explain later.
Practical consequence
It makes sense to track ARR and non-ARR revenue separately and report both. One-off revenue is not a flaw — it is simply another revenue type with different reliability. The error arises not from its existence but from its landing in a metric that explicitly excludes it.