How to define Annual Recurring Revenue
Unpack the business logic you need to establish a single source of truth for ARR.
This post is an adaptation of Chapter 4 of our book, The Ultimate Guide to ARR.
Join thousands of founders and finance professionals from Uber, Atlassian, Plaid, Retool, Intercom, and more, and get your free copy today.
In most SaaS companies, when you reach a certain scale, Finance has its own forecast, and Sales (or Sales Ops) tend to have their own. Your goal should be to align these two groups as closely as possible. Sales and Finance should walk into every forecast review with a tightly aligned view of the state of the business. It took us many iterations (and horrific meetings) to get there at Intercom.
There were many times over the first few months of that relationship when we’d walk into a Go-to-Market forecast review, and Sales would be calling a number millions off from what we were calling in Finance. We looked like buffoons.
This would happen for a variety of reasons. Sometimes, it was because the contract signed date in Salesforce differed from the invoice date. Other times, it would be because a customer would expand, and Sales would count that, but they’d miss the subsequent contraction event. Another time, a customer might sign a contract but not pay after three months. Finance would count that as a churn, but Sales wouldn’t.
We spent months and months reconciling these differences, mainly after the fact, after the painful meeting, and after the embarrassing show of ineptitude in front of the rest of the team.
This chapter is intended to help you not look like the buffoons we did.
As painful as it is to relive, Bobby’s story clarifies that having a single source of truth for ARR is critical to getting alignment across your business. How can you expect to take action and move the company forward if you can’t agree on where you are?
We’ll start by breaking down all the business considerations you need to work through to develop your own source of truth for ARR reporting. While it may seem overwhelming at first, planning this out ahead of time will save countless hours and many arguments debates down the line.
In short, we’ll cover the following topics and include recommendations and examples for each:
Defining a customer
Backing out discounts
Reporting on service vs. product-based charges
Treatment of overages (spend in excess of the contract amount)
Building off Subscriptions or Invoices
Defining a Customer
Deciding where to draw the line on what constitutes a “customer” is one of the most critical decisions in reporting on ARR, as it has implications for cohorting and the component parts of ARR. It’s also relevant to how other teams, like Sales and Support, will organize their teams.
Customer to subscription
What to consider: Can a customer have only one active subscription at any given time (1:1) or multiple concurrent subscriptions (1:many)?
What we recommend: Allowing multiple subscriptions to be mapped to a single customer is fine, especially if the buying consideration differs across product lines. Just ensure it’s clear in your logic that:
Gross New ARR is only counted on the first subscription start date
Churn is logged when the last active subscription is cancelled
Parent-child accounts
What to consider: How do you handle cases where you work with multiple subsidiaries that roll up to a single entity (e.g., WhatsApp and Instagram to Meta)?
What we recommend: Any entity with purchasing authority (i.e., can sign a contract) should be considered a customer. We like this definition because it fits well with how you would organize your Sales or Support team, as each entity will likely have its own instance of your product.
You should consider including a “Global Parent” field in your CRM to link sibling accounts to the same parent.
Counting customers
Depending on the buying process, there are several events to choose from as the point at which to start counting a customer for reporting purposes. Remember, this is especially important because it determines which cohort a customer belongs to and impacts operational elements like Sales compensation.
Here are a few things to keep in mind:
Trial periods
What to consider: If you offer a trial, do you wait until the trial expires or start counting at signup?
What we recommend: To reduce noise in your reporting and align to the moment where a customer has skin in the game, we suggest recording the revenue once the trial expires and the paid portion of the subscription starts.
Payment status
What to consider: Is getting to trial end and subscription start date enough, or should you wait until an invoice has been paid?
What we recommend: The answer depends on your go-to-market motion.
For companies with a PLG or Self-serve motion, it’s better not to count a customer as Gross New until their first invoice is paid. This will mitigate inflating Gross New and reduce immediate Churn from customers where money was never exchanged. This is less relevant for companies with a Sales-led motion, as customers have clearly demonstrated intent to pay when a contract is signed.
Contract start vs. booking date
What to consider: If customers must sign a contract before they can use your product, should you start counting them as customers on the signature or contract start date? What if the two dates fall into different reporting periods? It’s common for many deals to close on the last day of the quarter, but the contractual relationship begins in the following month.
What we recommend: You’ll hear many opinions on this topic, but we advise aligning the ARR recognition to the subscription start date. Doing so will inevitably create a dissonance between your Sales Bookings and ARR, but that can be solved by having a systematic way to bridge the two numbers. Just make it absolutely clear from leadership down to individual sales reps how the two differ. In cases where you want to drive better alignment, you can create incentives for sellers to pull forward contract start dates.
Discounts
In creating the logic for ARR reporting, it’s better to err on the side of conservatism. Reporting a higher number than you might get credit for by investors or the public market is a bad trade in the risk-reward spectrum.
That’s why adjusting for discounts in the ARR Build is important. However, not all discounts are created equally. There’s nuance in determining which should be removed and which can be ignored.
Let’s explore the differences based on the discount window.
Recurring discounts
What to consider: Do you handle discounts applied in perpetuity (forever) on a fixed dollar or percentage-off basis? We see many of these in custom pricing plans offered to early/legacy customers or those with “friends and family” type coupons.
What we recommend: This one’s pretty straightforward. You should always remove these from your ARR calculation because they happen on a recurring basis, like the revenue you’re annualizing.
Fixed-term discounts
What to consider: Discounts with a fixed start and end date are more open to interpretation because they’re recurring but only for a certain amount of time, e.g., 1, 3, 6, or 12 months. Common sources of these discounts are marketing promotions (e.g., three months free if you use code “xyz” at checkout), start-up plans (e.g., 50% off or a fixed price plan), or first-year discounts on multi-year Sales contracts.
What we recommend: In the spirit of conservatism, it’s better to remove these from your calculation and recognize Expansion when the discount expires. This also ensures you assign the right value between business impact and compensation targets for the company's go-to-market teams.
Credits and one-time adjustments
What to consider: The last bucket of discounts comes from credits and one-time adjustments. These are one-time and do not relate to the underlying subscription or product bundle. Examples include compensating a customer for a service outage or waiting too long in the customer support queue.
What we recommend: We do not recommend adjusting for these in ARR for two reasons:
The credits aren’t related to the purchase experience or the customer’s subscription
They are not controlled by the teams responsible for revenue (e.g., Sales, Marketing)
Refunds
Mistakes happen. That’s what refunds are for.
As an analyst, the problem is that refunds are often used as a catch-all for many things like:
Incorrect subscription set-up
A misunderstanding on pricing (e.g., “I didn’t know my bill was going
to 10x!”)
Poor customer experiences
They also restate historicals, which can drive you crazy when trying to reconcile performance data. Rather than walking through each permutation, we’ll share our guiding principles on refunds.
What to consider: Always work to fix the underlying issue in the correct upstream source (usually the subscription) and make the best effort to record the refund on the date it was processed instead of applying it retroactively (i.e., avoid historical restatement). The one exception to the latter point is if the refund amount is so high that it materially impacts performance or creates misleading results. For example, when a customer expands by $1M and your total ARR pre-expansion is only $200K. In those cases, applying it retroactively makes more sense.
Services and one-time charges
Many companies have service-based offerings in their product suite. This includes things like implementation or priority support.
Similar to discounts, the nature and duration of the service impact whether this revenue category should be included in ARR.
Non-recurring charges
What to consider: Fixed charges related to getting the customer onboarded through things like implementation and training.
What we recommend: We suggest not including these since they are non-recurring in nature. It also avoids a false signal of a Contraction once the implementation period ends.
Recurring service charges
What to consider: Other service-based charges that persist through the customer lifecycle, such as priority support.
What we recommend: It’s safe to include this in ARR, but we strongly recommend having a way to differentiate between service-based and product-based ARR. This will help you understand what value is assigned to each component and decide where to invest resources in the business. It’s also likely that investors will apply different valuation multiples to product vs. service-based ARR if you go through a fundraising process. It's better to know that upfront and be prepared.
Overages
Overages are usage in excess of the customer’s contract. They can apply to seat or usage-based pricing models. A quick example of overages might be if a customer signed a contract for 10 seats but currently has 12 seats in use.
Tracking overages is important because it gives you a sense of how much of your ARR is fixed (i.e., under contract) vs. variable. You may also charge different rates for usage within the contracted amount (through discounts) vs. in excess (through premiums).
There’s a quick, two-question test to see if this applies to your business:
First, do you offer annual contracts?
Second, can customers increase their usage beyond the contracted amount without signing an updated contract?
If you answered yes to both questions, you should read the following considerations carefully to determine how you want to handle overages in your ARR reporting.
Duration of overages
What to consider: How long do customers typically remain in an overage state once they are incurred?
What we recommend: Erring on the side of caution suggests not including overages, but the duration can help guide your decision if you’re on the fence. If customers stay in an overage state past their renewal period, you can probably get away with including them. The effect here is just recognizing the Expansion earlier.
Frequency of overages
What to consider: Independent of duration, is it more common for customers to move in and out of overages, or do they tend to stay there once they’re in that state?
What we recommend: If customers tend to move in and out of overages, it’s safer not to include that in your ARR calculation. Instead, you might want to focus on incentivizing your Sales team to bring those overages under contract before the customer’s usage comes back down.
Overage concentration
What to consider: How many of your customers are in an overage state, and what does the overage spend represent in terms of your total ARR?
What we recommend: If most of your customers are in an overage state and tend to stay in that state for a long time, you’re probably safe to include this in your ARR calculation. However, we advise you to frequently monitor usage patterns across your customer base, as this variable revenue can expose your business, especially in a changing economic environment.
Subscription vs. Invoice view
The final consideration in defining ARR is determining what object to model your reporting off—invoices or subscriptions. Let’s walk through both models' pros and cons to determine which is right for you.
Subscription-based view
Subscriptions are generally easier to work with because they have fewer edge cases than invoices. They’re also a better proxy for when a customer becomes active (i.e., subscription created) or inactive (i.e., subscription cancelled).
The biggest challenge to working with this object is ensuring you have the right historical event data to know exactly when and how changes were made to a subscription. Depending on your billing software, this may require the use of webhooks or snapshots of a data warehouse. Once you’ve established a process to track historical event data, you can accurately model a customer’s spending at any given time.
Invoice-based view
Because accessing historical event data on subscriptions can be challenging, many companies model ARR reporting off invoices in the early days.
Invoices provide a full historical archive of customer charges. Every invoice has a Start and End date, making it easy to create a time series view of how spend has evolved over time at the customer level.
While the time series view is easier to produce using the invoice-based method, it does come with a few drawbacks. Let’s walk through some of the most common cases below.
Timing
Not surprisingly, using the invoice-based method requires sending an invoice to start tracking ARR. However, it’s certainly not uncommon for there to be a delay between creating or updating a subscription and sending an invoice to a customer. Addressing this delay in invoicing after the fact may require you to back-date invoices, which can cause your historicals to restate.
Invoice delays
What to consider: How do you avoid gaps in reporting when invoices are delayed or haven’t been issued?
What we recommend: First, automate invoicing as much as you can. Second, if manual invoices need to be sent, create SLAs with your billing team on how quickly invoices will be issued after an event. This is a critical step in locking month–end or quarter–end reporting results. Be sure to communicate these timelines to other teams relying on ARR reporting and instruct them not to pull any ARR reporting until invoicing is complete.
Frequency
Most businesses have customers at different payment frequencies: monthly, quarterly, or annually.
What to consider: How do you compare spend on an apples-to-apples basis when customers are invoiced on different schedules?
What we recommend: Adjust every invoice down to the monthly level and annualize from there. This looks something like the below:
Overlapping invoices
In most cases, only one invoice per subscription at a time should be honored to avoid double counting.
Corrective and backdated invoices
In most cases, only one invoice per subscription at a time should be honored to avoid double counting.
What to consider: How do you avoid double counting when a corrective invoice was issued to resolve a mistake in a prior invoice?
What we recommend: In cases where multiple invoices were issued on the same day, it’s usually safe to honor the last invoice created on that date.
In cases where a backdated invoice was issued, we typically recommend counting the corrective invoice on its issue date (rather than its backdated start date) to avoid restating historicals. Hopefully, the backdated invoice volume will be low, allowing you to review each instance with your billing team to make a final call. If you find this is a more regular issue, an upstream operational change will likely be required to reduce the volume.
Here’s an example of a corrective invoice fix:
Step 1: Create the field
ROW_NUMBER() OVER (PARTITION BY customer_id, period_start_date ORDER
BY invoice_created DESC) AS invoice_number_by_dateThis creates a ranker by customer by period_start_date and sorts descending based on when the invoice was created
By doing this, the LAST invoice created among matching period_start_dates will return 1
Step 2: Apply a filter
Filter for invoice_number_by_date = 1 in your data pulls
Here’s an example of a backdated logic fix:
CASE WHEN invoice_created > invoice_period_start THEN invoice_created END AS period_start_clean Amendment invoices
The second common cause of invoice overlap is from amendment invoices. These come as a result of a customer’s subscription changing midway through the service period.
Here’s an example:
Customer A is billed monthly, has five seats on their subscription, and is invoiced on April 1st for $100 ($20 per seat per month).
On April 16th, they upgrade their subscription to include two more seats.
Rather than waiting to invoice Customer A for seven seats on May 1st, you issue a $20 prorated invoice ($20 * 2 seats * 50% of the month) for the 15 days the two seats are active in April, which were not included in the April 1st invoice.
What to consider: How do you avoid double counting when a prorated invoice was issued to resolve a mistake in a prior invoice?
What we recommend: You should send prorated invoices automatically to bridge the gap between the amendment and the next scheduled invoice. This is the most optimal solution for reporting and cash flow for your business.
There are two things we suggest doing when sending prorated invoices:
Adjust the end date of the original invoice up to the day before the prorated invoice (i.e., to April 15th in the example)
Gross up the invoice amount to what it would’ve been in a non- prorated environment. This will look something like the below:
Now that we’ve covered all the factors to consider when defining ARR for your business, you’re ready for the fun part—building it.