How to Set Revenue Architecture for B2B SaaS The Right Way
Why should you read this document?
First, let’s answer these questions. How easy is it to…
- … launch new products/packages?
- ... change pricing/packaging?
- … launch new GTM like self-serve or consumption?
- … enable self-serve upsells or in-product billing?
- … generate error-free invoices?
- … collect cash from your customers?
- … basic and correct SaaS metrics for your business?
- … generate correct revenue recognition data (ASC606)
In short, how easy is it for your customers to do business with you
If you answered “Yes, it is easy” for everything above, congratulations! You are set, and you don’t need this document.
If not, then read on.
Who is this document for, and what it answers?
B2B SaaS Founders — Revenue architecture is one of the least documented yet super critical to get it right for businesses 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?
What this document does not talk about
Tools like CRM, Accounting Systems, Tax Processors, Payment Processors, CLM, Sales Commissions, and Revenue Forecasting — not that these are not important, but just not in the scope of this document. Also, we don’t discuss any vendors in this document; we just talk about architecture.
Summary / TLDR;
- You should have a single source of truth for your product catalog across all channels in one system.
- Because of #1, your CPQ and Billing need to be combined in one system.
- Do not buy a separate metering tool—otherwise, it would violate #1. CPQ, billing, and metering should be in just one system—we will call this system the Enterprise Monetization Platform.
- You should strictly follow a 3-system architecture: CRM (source of truth for customers), Enterprise Monetization Platform (source of truth for GTM), and Accounting system (source of truth for financial data / general ledger)
What is Revenue Architecture?
It is the collection of tools/systems that help you earn Revenue.
These systems enable your Quote-to-cash process (see below), which starts when you send a quote to the prospect, send them an invoice, and then later collect cash from them.
The following tools implement this process:
- CPQ (Configure-Price-Quote) e.g., Salesforce CPQ, PandaDoc
(document generation tool aka poor man’s CPQ) or even Google Docs. - Billing systems, e.g., Stripe, Zuora, NetSuite Billing, etc.
- (More recently) Metering systems e.g., Metronome, etc.,
Why do you need to worry about it?
Few reasons:
- If you don’t set the Revenue Architecture properly, it negatively impacts your revenue — specifically, it will take longer to close deals, amendments (up-sells/cross-sells) will be hard to process, renewals will become painful, invoicing will be manual and error-prone, there will be both revenue loss and revenue leakage, customers will have a poor experience, and they eventually churn because it is hard to do business with you.
- Change management is a nightmare. It is common knowledge that most internal systems, such as CRM, HR systems, and recruiting tools, will evolve as your company grows. However, your revenue tools are like octopuses, tightly linked to your operations and your business. Change management at any stage for revenue systems is a massive undertaking in terms of time and money. As such, the earlier you get it right, the steeper your revenue growth curve will be.
- Getting it right is a strong competitive advantage — Picture the following: you are in the market to buy a product and come across two vendors with seemingly similar products. One makes it easy to do business, i.e., they send easy-to-understand quotes and fast, invoices are correct and transparent, and expansion/renewal and even contraction are easy. However, the other vendor makes it hard to do business with, i.e., long sales cycle with complex quotes, painful to do any upgrades/contraction/renewal, and invoices unclear, etc.; who will you prefer to do business with?
- There is surprisingly little to no literature on this subject—quote-to-cash is the most critical business process for any enterprise of any size. However, this topic is surprisingly under-documented primarily because it used to be a routine IT workflow (for non-SaaS). However, due to all the complexities of a SaaS business (see below), things are now beginning to change (like this article).
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.
Once upon a time, B2B was Non-SaaS
B2B was about selling hardware and widgets only. Send a quote to a customer with the products/prices/discounts. Negotiate and close the deal. The billing team picks up the quote, converts it to an invoice in their billing system, and sends the invoice out. The business gets paid. Open a bottle of Champagne. Life’s good.
Here is the tooling to enable the above workflow.
Sales used CRM and CPQ.
The 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.
Then came SaaS…
Well, now things are different. Actually, a whole lot different.
#1: One-and-done to Land-and-Expand
SaaS implies subscriptions, i.e., now there is a concept of time 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 make any amendments, it was a brand-new transaction with no correlation to the previous one. It was another one-and-done deal with a unidirectional 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 an upsell, the customer is now required to pay for the additional seats for the remainder of the contract period (this is 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 by 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.
How is this being solved today for SaaS?
Most traditional CPQ and billing tools have caught on to the abstraction of subscriptions (even though it's 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 that data transformation needs to happen to translate the CPQ product catalog into 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. For the 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, and delays in account receivables, and it 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.
What should be done instead?
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 are an oxymoron for SaaS. The right (and 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 from non-SaaaS.
#2: Pricing & Packaging Changes are Now Frequent
Earlier, due to the non-SaaS nature of the product (i.e., hardware and software licenses), new hardware and software were released in a few years, never in months, and certainly not in days.
Due to cloud delivery, you can now launch new features/packages rapidly. Pricing can be changed frequently (sometimes even weekly, though often monthly) to test pricing in new markets or segments. 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.
How is this being solved today for SaaS?
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 — it's not a vendor problem; it's the (wrong) architecture.
What should be done instead?
The right architecture choice here is obvious: having a single catalog shared between the CPQ and Billing tools. If the CPQ and Billing tools are from different vendors, this will never happen. Also, the approach of having a Product-Catalog-as-a-Service that is shared by different tools doesn’t work, as the product catalog is tightly coupled with the CPQ/Billing features. Such core functionality cannot be extracted. 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.
#3 Self-serve is the new way to sell
In the Non-SaaS world, the self-serve channel was non-existent.
However, for SaaS, self-serve/PLG (Product-Led Growth) is actually a key requirement. Even the ability to make self-serve amendments, i.e., in-app upsells/cross-sells, is now being demanded by 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).
How is this being solved today for SaaS?
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 do 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 backward?
What should be done instead?
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.
#4 Consumption-Billing is the New Business Model.
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 of 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 commitment (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 send usage data (often in real-time) and have it invoiced properly — none of this was
How is this being solved today for SaaS?
Engineering teams are buying “standalone” metering tools, which solve the problem of sending usage from the product to the new system. However, this seemingly simple change creates massive entropy/pain in the entire workflow, as now there are three disparate tools (CPQ, Billing, and Metering) instead of two (CPQ and Billing).
Someone needs to build connectivity (read more duct tape) between CPQ -> Metering and Metering -> Billing. Every change in GTM/pricing/packaging is now 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.
What should be done instead?
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.
Summary
Insight #1 — CPQ and Billing tools need to share the same product catalog and Contract abstraction; otherwise, there will always be dissonance in the Revenue Architecture. This implies that CPQ and Billing should be combined in one platform.
Insight #2—Such a system needs to connect seamlessly to your website or product. This implies that it needs to be API-first.
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.
