Why is SaaS Billing So Damn Hard?

Before launching MonetizeNow, nearly every CFO/CRO I conversed with expressed frustration about how challenging it is to manage SaaS amendments — be it upsells, downsells, or cross-sells — and that the it is a bottleneck in their company’s growth.
‍

On a pain scale of 1–10, this was mentioned as close to 10.
‍

At the time, I wondered why managing a recurring charge appeared such a challenging issue — it seemed like a straightforward technological problem.
‍

Well, as they say, the devil in the details.
‍

Let’s delve into the specifics to understand why this issue presents such a significant challenge.

Amendment Use Cases

First, let’s define the term Amendment in more detail.
‍

Amendment is any change to an existing contract. It could be any of the following:
‍

1. Upsells i.e., buying more of what you have already bought. Example — buy more seats or even buy a better version of the same product, i.e. upgrading to the Gold plan from the Silver plan.
   ‍
2. Cross-sells i.e., buying something new. Example — Figma user buying Figjam.
   ‍
3. Downsells i.e., buying less of what you bought earlier. Most businesses don’t allow downsells during the contract, but it often leads to bad blood. Instead of outright rejecting it, vendors could allow a reasonable downsell. The reason most vendors don’t support it today is also because it is almost impossible to support it operationally with the existing tooling.
   ‍
4. Co-term (short form of co-terminous), i.e., at the time of amendment, keeping the term length of the contract the same as the previous. This requires adjusting prices for the amendments for the remainder of the term (proration).
   ‍
5. Contract extension — it is possible that the changes requested are significant, and the customer requests more discount, and the vendor counters with extending the contract.
   ‍
6. Contract contraction — again, this is an unlikely scenario, but possible for a multi-year contract if some performance obligations are not being met, in which case instead of doing a contract cancellation right away, both parties negotiate a contraction instead.
   ‍
7. Price changes — It is possible that the price of a certain product is increased during the contract period and needs to be reflected for the remainder of the contract period. Note that most contracts (if written well), allow nominal (or at least inflation adjusted) price increments.
   ‍
8. Retiring an old product — Products get retired all the time, and the default action is usually to allow customers on existing contracts to keep having the same product, but in some cases it may be needed to change the product to a newer product (often at the same pricing).
   ‍

This list covers all the major/practical use cases for Amendments. If there are more, please email me or comment below.

‍

To understand the complexity of amendments, we will cover the most basic and common use case i.e., Upsells.

Why even the most basic use case of Upsell Fails?

Here’s the Upsell scenario:
‍

1. New business — Customer buys 100 seats for 1 year with monthly billing. No quoting complexity, and almost all traditional billing systems now implement subscriptions, so they can send periodic/monthly invoices. No issues here.
   ‍
2. Upsell — Customer loves the product and wants to buy additional 10 seats in the 2nd month. (This should be a reason to celebrate!)
   ‍
3. Common sense would say the CPQ needs to prorate 10 seats for the remaining 10 full months (and the partial month). The billing tool needs to send an invoice for 10 additional users for the remainder of the month, and for the next month send an invoice for 110 users.
   ‍

Sounds easy.
‍

Not so fast, Mr. Spock.
‍

There are 3 major problems.

#1. CRMs are not built for this

To represent the upsell deal of 10 users, sales reps create a new Opportunity (in SalesforSandeep Jaince lingo or Deals in Hubspot lingo) independent of the initial (new business) Opportunity.
‍

Why? Because that is the easiest thing to do.
‍

This approach has two big problems:
‍

First, since the new Opportunity is independent of the first Opportunity, the contract term for this Opportunity is an additional year (instead of co-terming with the first one). When the time comes for renewal for the first opportunity, everything goes for a toss. Do you renew 100 or 110? Do you even know that the customer bought 10 additional seats? What if there were multiple changes throughout the year?
‍

Second, the fact that the customer has now 110 users is lost, as that data is now split across multiple Opportunities. Imagine having multiple changes during the contract, and to understand what the customer owns is now spread across multiple opportunities, and it’s unclear what the customer really owns.
‍

The right way to solve this problem is if there was only one Contract, and CRMs were supported to amend the Contract.
‍

Some CRMs don’t even support an abstraction for a contract, e.g., HubSpot CRM doesn’t even have that concept, which means if you are using HubSpot, running your SaaS business on top of it will have challenges. That is another reason why using HubSpot Quotes is not such a smart idea for SaaS businesses.

Note that Salesforce CRM supports it, but it’s underutilized, as this requires building a lot of logic around it / buying their CPQ (which is a massive lift in terms of time and money).
‍

Fun Fact — 80%+ of SaaS business are still doing things the above way, i.e., using an independent opportunity to do amendments.
‍

#2. CPQs are not built for this

Even if CRM supports contracts, most CPQs don’t support it. So how do you represent this? There are two ways to do this:
‍

Sales rep sends 1 quote for 10 users for an additional year.

This is the scenario discussed above, which creates a new opportunity with a new contract term — this will cause massive issues for further amendments and finally the renewal.
‍

Sale rep sends a cancellation quote for 100 users and a new quote for 110 users.

This approach creates more trouble, but is still in use by most businesses. This causes massive issues with billing, provisioning and even reporting, as it makes it look like the customer churned, and then they renewed.

As you can see, both approaches are super painful.
‍

#3 And billing tools are not built for this either

As we saw earlier, the billing tool needs to generate an invoice for 10 additional users for the remainder of the month, and then beginning the new month send an invoice for 110 users.
‍

There are 2 ways to solve this:
‍

Transfer information from CPQ to billing manually

CPQ and billing tools were not designed to interoperate, so most SaaS businesses manually review the quote and then generate an invoice. This is a highly time-consuming and error-prone process, which for high-volume SaaS businesses creates a massive headache for billing operations, creating downstream issues of deluge of billing inquiries, revenue leakage and revenue collection problems.
‍

Connect CPQ and Billing via the CRM

All CPQ tools are designed to connect to the CRM — that is understandable, since a deal originates from the CRM. However, billing tools were not designed to connect with the CRM, and most billing tools don’t even support the concept of a Contract. We also noted earlier that most CRMs don’t even support a contract abstraction.
‍

What this means is that data flow from CPQ -> CRM -> Billing is guaranteed to be lossy. When you hear someone say there is a brittle connection between the tools, they refer to this issue.
‍

This is the #1 reason why all standalone billing tools (including Stripe, Chargebee, Maxio, Ordway… the list goes on) are flat-lining. The CRM to Billing transition is breaking down and makes SaaS Billing so damn hard.
‍

Note that the above was just for the very simple use of Upsell and even then the most simplest scenario for Upsell.

‍

In reality, things are more complicated, in fact, much more complicated.

1. What if there is tier-based pricing on the seats, which means the customer gets lower pricing for the additional 10 seats?
   ‍
2. What if the customer wants to get more discount for the additional seats (or maybe for the entire seats) because they are buying more seats and the rep wants to increase the contract length?
   ‍
3. What if the 10 user upgrade is not for now, but in the future? Billing tools are designed around Subscriptions — for subscriptions, any change is immediately reflected. To program a change for the future, a separate abstraction (Contract) is required. However, none of the billing systems are designed around this.
   ‍
4. What if there are several amendments throughout the year?
   ‍
5. Given the growth in seats, what if the rep wants to create a ramped upsell deal, i.e., 110 users for the first 3 months (including the partial 2nd month) and then 200 users for the remaining 8 months? i.e., bake-in the growth in the upsell business deal in exchange of better discounts. This is a win-win for both your customer and you. However, this requires data model compatibility between the CPQ and billing systems to do this effortlessly. The reality is that it is so painfully hard to manually do, that almost no one supports it, even though it is the most desired outcome.
   ‍
6. Most customers don’t prefer calling sales reps just for adding a few seats. Sales reps also don’t want to engage in such conversations, as such deals have low sales commissions. What if you can allow your end-customers to do such changes from within your product? However, current CPQs don’t support it.
   ‍
7. Even better, what if there was a frictionless way for adding seats, which doesn’t require any action from the rep or your end customer? I am talking about usage-based pricing. In this case, if the customer used more than 100 seats, they would be automatically charged for those extra seats at the end of the month. Wouldn’t that be super nice! However, CPQ systems should be able to quote for usage, and billing systems should receive usage and generate just one invoice with both the subscription (100 users) and overage. Sounds easy, but traditional billing systems were not designed to support this complexity. What is being done today is either people are building this metering tool in-house or buying a new metering tool, which likely doesn’t support the contract abstraction either. So, now you have 3 disparate tools (CPQ, Billing, Metering) that may not support contract abstraction and are guaranteed to have a different data model. When people refer to connecting these tools as “duct-tape”, you can see what they are referring to — its not a simple API connection, but multiple data transformations and custom logic.
   ‍

You can now probably appreciate why your RevOps and Billing teams struggle today.
‍

And we haven’t even gone into the other use cases of Amendments.

What’s the solution then?

Let’s use the first-principles based approach here.
‍

First, CPQ and billing tools both need to support the Contract abstraction.
‍

Second, CPQ and billing tools need to be connected together, instead of going through a CRM that may or may not support Contracts.
‍

This implies that CPQ and Billing must be in the same platform.
‍

If CPQ and Billing are different tools, they may or may not support Contract abstraction, and even if they do, the Contract data model will be different. Also, they will have different underlying product catalog data models, which will further make the job of connecting these tools very hard. As such, the only way to ensure that SaaS amendments work well is to combine the CPQ and Billing in one platform.
‍

Third, to support PLG/in-product use cases, this platform should be API-first.
‍

Fourth, such a system needs to support metering both natively and with scale, i.e., ability to consume tons of usage data. Metering should not be done in a separate tool, for all the reasons why CPQ and Billing cannot be separate tools.
‍

This is nothing but a Centralized Revenue Architecture.

‍