How to Set Revenue Architecture for B2B SaaS The Right Way

by

Sandeep Jain

   |    

September 5, 2024

How to Set Revenue Architecture for B2B SaaS The Right Way
How to Set Revenue Architecture for B2B SaaS The Right Way

Why should you read this document?

  1. How easily can you launch new products/packages?
  2. How easily can you re-package?
  3. How easily can you change pricing?
  4. How easy is it for your prospects to do business with you?
  5. How easy is it for your customers to do more business with you? Can they do cross-channel, i.e., buy through a rep initially, but upgrade self-serve?
  6. How easy is it to generate error-free invoices?
  7. How easy is it for your customers to understand your invoices?
  8. How easy is it for you to collect cash from your customers?
  9. How easy is it to get basic SaaS metrics for your business?
  10. How easy it is for you to launch new GTM motions like self-serve or usage?

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.

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 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?

What this document does not talk about

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.

TLDR;

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”.

What is 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:

  1. CPQ (Configure-Price-Quote) like Salesforce CPQ or poor-man’s CPQ — these are either DIY solutions like Google Docs or document generation tools like PandaDoc that generate a nice-looking PDF.
  2. Billing systems e.g., Stripe, Zuora, NetSuite Billing etc.,
  3. (More recently) Metering systems e.g., Metronome, etc.,

Terminology Soup related to Quote-to-Cash

Why do you need to worry about it?

Few reasons:

  1. If you don’t set the Reveue 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 poor experience, and they eventually churn because it is hard to do business with you.
  2. Change management is a nightmare — it is common knowledge that most internal systems will evolve as your company grows. e.g., CRM, HR systems, recruiting tools etc. 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.
  3. Getting it right is a strong competitive advantage — Picture the following: you are in the market to buy a product, and you 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, expansion/renewal and even contraction is 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, invoices are unclear etc., Who will you prefer to do business with?
  4. 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), but 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/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.

Traditional Revenue Architecture (for Non-SaaS)

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.

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 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.

How is this being solved today for SaaS?

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.

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 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.

Supporting SaaS requires CPQ and Billing to be in one platform

#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 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.

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 — its not a vendor problem, its the (wrong) architecture.

What should be done instead?

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.

SaaS needs Unified Catalog across CPQ and Billing

#3 Self-serve is the new way to sell

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).

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 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?

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.

Self-Serve is Best Supported by API-First CPQ+Billing Platform

#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 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

How is this being solved today for SaaS?

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.

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.

Metering is a feature and not a product

Summary

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.

Share this article

Subscribe to our blog

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.