*Co-written with our friend at Preql.

In order to be successful, companies must align around a single metric. It’s the way to ensure every team is focused on one tangible goal that everyone understands and can work towards. Revenue is almost always a component of that metric regardless of the type of company or industry you work in.

If you’ve worked for a SaaS company, you’ve likely heard your team discussing Annual Recurring Revenue (ARR): the north-star metric for most SaaS companies. In this blog post, we’ll cover why it’s so important, things to consider when reporting on ARR and how to calculate it.

Why is ARR so important?

There are a few reasons ARR is such an important metric for SaaS orgs, starting with the fact that venture capitalists and SaaS investors are most focused on this number.

ARR refers to the sum of recurring revenue generated by customers over a 12 month period. Given the annual and often high renewal rate of SaaS contracts, ARR combined with some other metrics (net dollar retention, gross retention, growth rate, etc.) is often used to benchmark the stage and trajectory of a business, and therefore its attractiveness as an investment.

Historically companies have needed to hit certain ARR milestones to be considered optimal investments for their next round of fundraising. For example, reaching $1M ARR pairs with raising a Series A or $10M ARR signals eligibility for a Series B. During especially bullish markets certain companies (currently those building generative AI) can completely ignore these benchmarks and raise millions of dollars on their ideas alone. Regardless, ARR continues to be the strongest metric SaaS companies use to measure their overall performance and growth path.

The ARR gray area

Most metrics in finance must adhere to standardized accounting practices known as Generally Accepted Accounting Principles (GAAP). This ensures that when investors in publicly traded companies are evaluating companies, they are comparing apples-to-apples. ARR, however, is not a GAAP metric, and therefore there is more interpretation into the “correct” way to calculate them. More interpretation leads to more variability across companies.

Some questions to ask yourself before getting started:

1. Which line items in our quotes are truly recurring?
2. When do we start counting new ARR: On the day the contract is signed or the effective date of the contract?
3. When do we decrease our ARR for churned accounts? Upon notice of churn, expiration, or some later date?
4. How do you handle late renewals? Is it churn that is re-added?
5. How do you recognize ARR in a multi-year contract where the contracted amount increases year over year? ($100,000 in year 1, $125,000 in year 2, and $150,000 in year 3)
6. Do you calculate a monthly rate and multiply it by 12, or calculate a daily rate and multiply it by 365 (or 366 in a leap year)?
7. How do you handle free access to a product for a period of time in conjunction with a signed contract (also known as a baker’s dozen — 13 months for the price of 12)

The truth is, there is no absolutely right answer to these questions, and many of them depend on your company. That said, we want to propose a consistent and defensible approach to calculating this metric.

Core principles:

1. Consistency is key. In general, once you codify your rules you should apply them to all deals. Treating each deal differently leads to a lack of credibility in one of your most important metrics.
2. Understand the difference between Contracted and Under Contract ARR. People often conflate the two versions of ARR: Contracted ARR (what is agreed to in contract) and Under Contract ARR (ARR that is currently between the contract start dates and end dates). Clearly delineating between the two makes it easier to answer some of the above questions.
3. Calculate ARR by finding the daily rate and multiplying it by 365 as opposed to a monthly rate. The reason for this is that not all months are created equal (some have 30 days, some 31, and then there’s February 🙃). In the event where a contract doesn’t align with the monthly calendar (i.e. January 1, 2023 to February 17, 2024), it makes your calculation that much more variable. This does, however, come with the trade off that your ARR numbers may not be as “neat”: A $50,000 recurring revenue deal from January 1st to June 30th (six months, but 181 days) will have an ARR of $101,828.73 instead of $100,000. Comparatively, a deal from July 1st to December 31st (also six months but 184 days) will have an ARR of $99,184.78).
4. Have clear internal guidelines about how to input opportunities in your CRM. Making decisions about how to handle multi-year deals, baker’s dozens and more can be handled with process rather than tech. Just remember not to over-complicate it — if it’s too hard to remember, your reps will never follow the process.

Unlock your Salesforce cheat code with Sweep. Book a demo today (https://www.sweep.io/book-a-demo/?utm_source=email_signature).

Putting this into practice:

If you’re calculating ARR in a CRM

Building a solution that removes the grunt-work from calculating this metric is a useful exercise. In order to build this in a CRM, there are a few key items at play:

1. Identify which products you sell that count as recurring revenue. This can be done by adding a checkbox for “Recurring” on the product or quote object in your CRM
2. Capture the contract start date and end date to understand how long the contract is for. If you are missing either or both of those metrics, assume the contract is annual.
3. Divide the key financial field. In your CRM, this could be the amount field, or some other field that calculates the amount of recurring revenue, and should be equal to the sum of the prices of your recurring revenue line items.
4. Run the calculation to divide the recurring revenue by the length of the contract, and then multiplying by 365 (or 366 if it contains a leap year).
5. Roll this metric up to a parent object so that if there are multiple deals closed in a year, you can associate the various deals to one place, and understand what was under contract in a given year. In Salesforce, a good option is the contract object.

Calculating ARR within a single CRM is beneficial for many early-stage or smaller-scale companies. However, as businesses evolve and begin to diversify their tools, this landscape shifts. When scale and complexity of operations grow, businesses often find themselves juggling multiple systems and databases (i.e. Salesforce, Netsuite, Stripe, etc). This introduces challenges, but also opportunities for a more granular and insightful analysis of ARR.

Successfully managing ARR calculations from different sources requires careful management of the individual CRM source data as well as consistent application of business logic. The CRM often serves as the backbone of your revenue data, containing invaluable information on customer interactions, deals, and contracts. When integrating with other data sources, inconsistencies or inaccuracies in your CRM can ripple through, compounding errors, and skewing insights. It’s much harder to apply fixes to downstream calculations for ARR than it is to solve data issues at the source. Sweep (https://www.sweep.io/) makes it easy to maintain and enforce consistency company-wide, helping you generate reliable metrics from single, or multiple sources.

Let’s delve into how you can navigate the intricate waters of calculating ARR when dealing with data spread across various sources.

Calculating ARR across many data sources

In order to get an accurate calculation for ARR in these more complicated scenarios, the underlying data has to be cleaned and carefully cultivated.

The series of steps this requires will vary depending on the source systems in question, but in general it will look something like:

Step 1: Replicate data from your source systems into a central storage solution (e.g., Snowflake or BigQuery) via data ingestion tools such as Fivetran.

Step 2: Decide as an organization how the data from these sources needs to be cleaned/transformed to support the calculation.

• This step can be very complicated.Revenue is often double represented when multiple sources are being used (showing up in an accounting tool like Netsuite, and a point of sale tool like Stripe, for example) so a source of truth has to be decided, and then duplicated revenue has to be removed.
• This is also the step where edge cases need to be accounted for and handled consistently across data sources. If you decide a certain plan or product should count towards your ARR, it needs to count regardless of the source system. If you’ve opted to spread revenue for calculation daily, the same needs to hold true for each source.
• Another challenge in this area is that some source systems offer their own ARR calculations, but do not expose the underlying logic of those numbers. This means either using the source systems’ derived numbers and dealing with the potential inconsistency, or calculating all source systems’ ARR from scratch.

Step 3: Implement this logic in SQL, then create and schedule a series of transformation scripts that will serve as the base for your ARR calculations. Managing the freshness of your underlying data and the cadence of updates is crucial to preventing erroneous ARR calculations from missing or incorrect data (from a source system lagging on updates while your transformation script runs and delivers your ARR, for example).

Step 4: Build your final ARR query. ARR is generally derived from Monthly Recurring Revenue (MRR) or Daily Recurring Revenue. Calculating ARR could be as simple as summing this over a certain time period, similar to using the formulas from the CRM example above where the ARR is spread and divided by day. More complicated examples could involve creating this spread in the final calculation, and then grouping by date, or creating a SQL query that allows ARR to be sliced dimensionally by product type or other categories to add nuance to downstream reporting.

Step 5: Finally, expose your ARR metric in a tool the business can leverage. The underlying table can be pushed into a BI tool like Tableau or Looker where business users can refer to it and create their own dashboards or view reports that a data team has built for them.

Interested in learning more? Book a demo here

This blog post was co-written with our friends at Preql