by
Sandeep Jain
September 5, 2024
If you answered, “Yes, it is easy” for everything above, then congratulations! You are set and you don’t need this document.
If not, then read on.
B2B SaaS Founders — Revenue architecture is one of the least documented, yet super critical to get it right for business of any size. How to set it up the best way for B2B SaaS (subscriptions + usage).
Executives (COO/CFO/CRO) — Seasoned execs know that RevOps is a very thorny issue today. Is this a tool problem or an architecture problem? Is there a way out?
Engineering / Product — How do I think about Metering (Build or buy)? How to think about it relative to other systems like CPQ and Billing?
Tools like CRM, Accounting Systems, Tax Processors, Payment Processors, CLM, Sales Commissions, Revenue Forecasting — not that these are not important, but just not in the scope of this document. Also, we don’t talk about any vendors here, just pure architecture.
You need a Unified Revenue Architecture to provide the best revenue experience to your customers.
It combines Quoting (sending a quote to a customer; it is not just a document generation process), Invoicing (sending an invoice and receiving payment) and Metering (or consumption-based billing, i.e., charging customers based on what they use) in one Single Platform — hence “Unified” Revenue Architecture”.
It is the collection of tools / systems that help you earn Revenue.
These are the systems that enable your Quote-to-cash process (see below), i.e., starting from when you send a quote to the prospect, sending them an invoice, and then later collecting cash from them.
The following tools implement this process:
Few reasons:
In summary, if you don’t set this well, it will negatively impact…
… your Revenue Experience.
… your Revenue Velocity.
… and ultimately your business trajectory.
But let’s return to Revenue Architecture.
To understand the present, we first need to understand the past.
B2B was about selling hardware/widgets only. Send a quote to a customer with the products/prices/discounts. Negotiate and close the deal. Billing team picks up the quote, converts it to an invoice in their billing system, and sends the invoice out. Business gets paid. Open a bottle of Champagne. Life’s good.
Here was the tooling to enable the above workflow.
Sales used CRM and CPQ.
Finance team used Billing and Accounting.
The sales motion was uni-directional due to one-and-done sales. CPQ and Billing interface was manual (but no one cared, as this is the world of low-volume/high-dollar deals).
Again, life was perfect.
Well, now things are different. Actually, a whole lot different.
SaaS implies subscriptions, i.e., now there is a concept of time related to the purchase that didn’t exist before (purchase was for the lifetime).
Second, SaaS is about land-and-expand, which implies you want the customer to return within the contract period and buy more from you. We will call these amendments — they can be of any type, i.e., upsells (buy more of the same product), cross-sells (buy different products) and even in some cases down-sells (buy less of what you bought earlier).
These seemingly simple changes actually turn everything upside down.
Why?
In the case of Non-SaaS, if the customer wanted to do any amendments, it was a brand new transaction with no correlation to the previous one. Another one-and-done deal with uni-directional flow of information from CPQ to billing. Easy peasy.
However, for SaaS, both transactions now need to be linked, as the new change requested is in the context of the previous one, often keeping the contract length the same.
If we take the simple case of upsell, the customer is now required to pay for the additional seats for the remainder of the contract period (also called proration, i.e., you need to adjust the total amount based on the remainder of the period).
That implies that CPQ now needs to maintain a new abstraction (we will call this Contract) to process an amendment. Also, this contract needs to be shared with the billing system, so that it can calculate the invoice amount correctly. Note that replicating everything on the Quote to the Invoice won’t always work — for example, if the Quote is for 1 year, while billing is monthly, to process the amendment, an invoice needs to be generated for the partial month first.
To read more about this, check “Why SaaS Billing is So Damn Hard”.
Above is the simplest case.
How about a situation where the customer wants more discount, and the sales rep counters with extending the contract period? What if the customer wants to buy another module during this transaction? For such scenarios, it takes days for CPQ and billing tools to generate a quote and an invoice. Such scenarios will take days to create and invoice. This is where the “deal desk” comes to life, where people try to manually create a quote and then later an invoice.
Most traditional CPQ and billing tools have caught on to the abstraction of subscriptions (even though janky) but the biggest rub here is that none of the billing tools support a good abstraction of contracts. The billing tools are designed to process changes in real-time (on subscriptions), but don’t have a way to model “future” changes. This is the core reason why most billing teams suffer today.
Also, even if CPQ and Billing now provide some sort of APIs, they are not interconnected for two reasons. CPQ and Billing tools (like any other separate tools) have different data models, which means many data transformation needs to happen to translate CPQ product catalog to a Billing product catalog. Furthermore, there is another vector of the contract setup itself, i.e., imagine a 1 year contract with monthly minimum payments that ramp up each month. Both CPQ and Billing need to support such abstraction. Most billing tools don’t even support the abstraction of contracts, which means more custom code.
Coming back to how things are getting done today — CPQ and billing tools instead connect via the CRM. Due to reasons mentioned above, the CRM -> Billing connection is usually very brittle, which leads to a complete breakdown of the invoicing side of the equation. This leads to manual invoicing, errors, delays in account receivables, and often leads to revenue leakage, customer dissatisfaction and sometimes even churn.
This is the architecture today and the #1 reason why your RevOps teams, Sales and Finance are suffering endlessly.
It must be abundantly clear at this point that separate CPQ and billing tools always cause friction. In fact, best-of-breed CPQ and best-of-breed Billing is an oxymoron for SaaS. The right (& the only) fix is for the CPQ and Billing functionality to come together in a single platform. Yes, this is a dramatically different architecture than before, but then SaaS is dramatically different than Non-SaaS.
Earlier, due to the Non-SaaS nature of the product (i.e. hardware and software licenses), new hardware and software was released in a few years, never in months, and certainly not in days.
With SaaS, new features/packages can be launched rapidly due to cloud delivery. To test pricing in new markets or segments, pricing can be changed frequently (sometimes even weekly, though often monthly). All of this requires frequent changes to both CPQ and Billing product catalogs (a product catalog is how you model what you want to sell or invoice, e.g., bundles vs SKUs etc.,).
However, this is a huge problem, as existing CPQ and billing tools have disparate product catalogs. Every tool (whether CPQ or Billing) implements its own product catalog, leading to disparate catalogs.
Many data transformations are happening to normalize the disparateness of the product catalogs using both iPaaS systems and a heavy dose of ongoing professional services. This is an extremely painful process, costing both time and money. Worse, this is a downward spiral, as with every GTM change, more duct-tape is added, leading to a point where “CPQ or Billing is now broken” and consultants come swooping in recommending new vendors. However, everyone misses the core issue — its not a vendor problem, its the (wrong) architecture.
The right architecture choice here is obvious i.e., having a single catalog that is shared between both the CPQ and Billing tools. If the CPQ and Billing tools are from different vendors, this will never happen. If you are an engineer, and are thinking why not do Product-Catalog-as-a-Service that different tools can share, well this approach doesn’t work as product-catalog is tightly coupled with the CPQ/Billing features and such core functionality cannot be extracted out — think of the product catalog as the engine of the car — all machinery in the car is tied to the engine. The only way to solve this is to have CPQ and Billing come together in one platform.
In the Non-SaaS world, self-serve channel was non-existent.
However, for SaaS, self-serve/PLG (Product-Led Growth) is actually a key requirement. Even the ability to do self-serve amendments i.e., in-app upsells/cross-sells is now being demanded by the end-customers.
However, supporting self-serve is a major problem as existing CPQ tools were built to be tethered to the CRM (no APIs). Billing was manual as well (again no APIs). Moreover, the quoting experience for an end-user is very different (and simple) than the quoting experience for a sales rep (more complex).
The engineering team is doing a custom build for the self-serve catalog and using a newer billing system (that supports APIs) to do self-serve. Problem with this approach — now the product catalog is in 4 different places — self-serve catalog code, newer billing system, existing CPQ and a separate (and more mature) enterprise-billing system. If you want to change pricing/packaging, not only you need to touch 4 different product catalogs, it is likely that one (or more) of them cannot do what you want to do. In other words, your GTM will be decided by the least common denominator of the catalogs instead of by you. Isn’t that backwards?
The combined CPQ and Billing platform needs to be API-first. Think of a headless monetization system that can be plugged into a website as easily as inside a SaaS product and even a CRM i.e., agnostic to the channel where your customer came from.
In the Non-SaaS world, consumption-billing in B2B was unheard of.
However, consumption-based business models are gaining popularity due to Gen AI (API-based) and a push from the market around paying for what one actually uses instead of the (usually inflated) subscription business model.
To support consumption, the usage from the product needs to be captured and metered.
However, existing CPQ and Billing tools were not built to support usage. Quoting Usage requires newer concepts like minimum commit (which could be across a subset of usage products), pre-paid credits, overage pricing and many more. To invoice for Usage, Billing systems need to be able to be sent usage data (often in real-time) and have it invoiced properly — none of this was
Engineering teams are buying “standalone” metering tools which solves the problem of sending usage from product to the new system. However, this seemingly simple change creates massive entropy/pain in the entire workflow as now there are 3 disparate tools (CPQ, Billing and Metering) instead of 2 (CPQ and Billing). Someone needs to build connectivity (read more duct-tape) between CPQ -> Metering and Metering -> Billing. Every change in GTM/pricing/packaging now is even more painful costing more money and time. Result — eventually the proverbial sh$t hits the ceiling; people are blamed/replaced, tools are blamed/replaced and the saga continues.
It should be logically clear at this stage that a separate metering tool is the problem here. Ideally, the billing system should be able to handle all metering functionality.
Insight #1 — CPQ and Billing tools need to share the same product catalog and the Contract abstraction otherwise there will always be dissonance in the Revenue Architecture. This implies CPQ and Billing should be combined in one platform.
Insight #2 — Such a system needs to connect seamlessly to your website/product. This implies it needs to be an API-first system.
Insight #3 — Such a system needs to support metering natively. This implies it needs to have a scalable architecture with APIs that support ingestion of (lot of) usage data.
.png)
