The Mistake We Made in Measuring Our Revenue: Confusing Bookings Revenue with MRR
CEO and co-founder @ Buffer
We recently realized that we have been miscalculating our true monthly and annual recurring revenue. I wanted to write up some of the details around this and also apologize for accidentally misleading as a result of getting it wrong. With our commitment to transparency (and the fact we’re rare in sharing our revenue numbers at all) I felt it’s even more important to share our error.
We’ve always reported “Annual revenue run rate” and “Revenue” for the month in our investor updates. The way we’ve measured “Revenue” has been to take the total revenue we generated in the month, and use that. For “Annual revenue run rate,” we simply multiplied monthly revenue by 12. Our revenue includes people who pay us on a monthly basis and also those who pay for the whole year in advance. This is where the miscalculation lies. As a recurring revenue (SaaS) business, we can’t guarantee we will get the same number of people paying for annual subscriptions month after month, and we are counting revenue that is in the future. The correct way is to ‘amortize’ and divide those annual payments by 12. In this way, we’re only counting the next 12 months of actual recurring revenue we have already acquired.
The total revenue we’ve used so far is still useful in terms of cash-flow, however it’s not the right method and gives a wrong number for people who might compare or look at how Buffer is doing. We like to measure cash-flow because it can be higher than Monthly Recurring Revenue (MRR), and we are hiring and making other spending decisions based on our cash-flow at times, not necessarily based on MRR.
So from now on, we plan to share both of these numbers. We’ll share our previous number as “Bookings revenue” and share “MRR” as well.
We’ve been lucky enough to have conversations with Hiten Shah, Jason Lemkin, and Eric Ries recently and managed to get confirmation from all of them that MRR is the correct measurement for us to use.
We’re excited to move to measuring MRR, since it’s a very powerful and helpful number for us to use and try to move each month.
I thought it might be interesting to share some numbers and comparisons about our MRR vs Bookings revenue:
MRR growth has been steady and strong. Bookings revenue growth is a little more erratic:
It’s rather fascinating to overlay these two measures of revenue, and see the pattern over time:
Overall, our bookings revenue was consistently 20 to 30 percent higher than MRR. In the recent months, we adjusted to annual pricing being the default for new customers (with the option to go for monthly payments instead) and so the percent difference has risen. In addition, our bookings revenue includes refunds and failed payments, and for our MRR number we’ve taken those out, so it drops further.
I want to say sorry once again for everyone in the community we might have misled with this mistake. We’re very grateful that so many of you follow along and join in the discussion around how we build Buffer.
Let me know if you have any thoughts or questions about this, I’d love to hear from you!
Try Buffer for free
140,000+ small businesses like yours use Buffer to build their brand on social media every month
Get started nowRelated Articles
Nine years ago, we decided to launch a new free product alongside Buffer. We called it Pablo, and it was a huge hit in our community. Within just seven months of its launch, half a million photos were created using Pablo. Similarly, we had the initial ideas for Stories Creator and Remix many years ago now. All three of these tools have been an important part of Buffer’s story. They’ve taught us lessons and helped us connect with a wider audience. In Pablo’s case, the idea for this tool happene
If you use Buffer, you might have experienced us having more downtime than usual recently. We want to start with an apology for not sharing more transparently along the way what’s been happening. We’ve been caught up in the work and haven’t invested enough in communicating with our community, and we’re so sorry about this misstep. We know some of our customers have had a frustrating time using Buffer recently and we need to do better by you. This past August and September were the months we’ve
As part of our commitment to transparency and building in public, Buffer engineer Joe Birch shares how we’re doing this for our own GraphQL API via the use of GitHub Actions.
