The next big SaaS player will be the company that solves enterprise billing

This was the headline of a thought-provoking article recently published in the Protocol. The article was well researched and it talked about issues with the current billing systems. Specifically, it mentioned:

While there are some products in the market like Zuora, Chargebee, Chargify and Stripe, they’re either not good at handling new pricing structures like consumption-based pricing, are lengthy to integrate or aren’t accessible to enterprises, according to industry sources interviewed by Protocol.

In this post, I will analyze the above statement and focus on the “why” (I am a big fan of the “5 whys” approach for learning). 

1. “Not good at handling new pricing structures like consumption-based pricing” 

Let's examine the first part – why are the products not good at handling new pricing structures. 

In any billing system, the pricing structures are modeled through the product catalog. If the product catalog is not designed right, modeling any new packaging / pricing becomes hard or sometimes even impossible. The next logical question then is why do the vendors not design the product catalog right. 

Most (if not all) vendors started with solving subscriptions billing for B2C (instead of B2B). Even if it was for B2B, it was mid-market use. In either case, the packaging/pricing requirements are usually straightforward and consequently the underlying product catalog is rather simple. Think of this use case like Netflix subscriptions (B2C) or New York Times selling subscriptions to businesses (B2B mid market use case). The “enterprise” use case for B2B is a completely different thing though as the packaging and pricing are quite complex e.g., combination of subscription, one-time, add-ons, usage with prepaid commitment and drawn down for multiple usage products etc., Modeling this type of catalog requires a completely different approach and considering that product catalog is the central pillar of any billing system, changing a product catalog is akin to changing engines of a flying airplane. That’s the reason why many billing vendors struggle to meet the requirements of “upmarket” customers. When customers say that they are “outgrowing” their billing system, it is highly likely that their packaging needs have outgrown what their current billing system can provide. 

Now, let’s examine the second part – consumption-based pricing.

For any system to consume large amounts of data (especially in real-time) requires significant data infrastructure plumbing upfront. Traditional billing systems were not built with this requirement in mind and consequently the only way they support usage-billing is by manually uploading usage data or some throughput way of consuming usage (through APIs). Either of these approaches are super restrictive and that’s what forces customers to look for either to invest in homegrown duct-tape or buy another tool that does usage-billing (but this approach has severe drawbacks as well as now more duct-tape is needed to connect this system to the CPQ, enterprise billing and the self-serve billing solution. I will examine this in a separate blog post)

2. “... are lengthy to integrate”

For enabling self-service (which is a mandatory use case for B2C and for product-led B2B), billing systems need to be integrated with the website (i.e., simple shopping cart like experience). This has been a solved problem for sometime now and relatively easy to do. 

B2B enterprises, however, have another channel i.e., the sales-led channel where the point of origin is the CRM. Sales people use a tool called CPQ (Configure Price Quote) to configure the deal for the enterprise customers (this is the “contact us” part of the pricing plans that you see on the webpage of B2B enterprises). The billing system needs to be integrated with this system as well and this is where the problem lies.

The CPQ - Billing handoff is around quotes i.e., CPQ system hands over the quote document to the billing system that in turn needs to generate an invoice. The core information on a quote is the product/packaging/pricing that is being sold to the customer – it is nothing but the reflection of the product catalog on the CPQ system. To be able to convert a quote to an invoice, the billing system essentially needs to convert the CPQ product catalog to the billing product catalog. The problem is related to what I discussed in #1 above i.e., the product catalog. The product catalogs in CPQ and billing systems are different as these products are built by different vendors with different constructs and translating one to another introduces complexity. Another (big) issue is that most of these systems were not designed with APIs in mind, so connecting these systems creates even more complexity. (Careful readers may note that Stripe is mentioned as one of the billing vendors and they are known for their APIs so what’s the problem there - the issue there is that of the CPQ systems which have severely lagged behind in their API capabilities). Both these reasons make the CPQ-Billing integration hard. 

As regards the downstream Billing and Accounting system interface, it is generally not an issue as the integration is around sub-ledgers and ledgers which are relatively standard.

3 “...not accessible to Enterprises” 

It seems that the author meant to say “not relevant to the Enterprises” instead.

For the reasons mentioned above, it will be extremely rare to find any high-growth enterprise with more than $20M in revenue using one of these systems. The challenge with high-growth enterprises is that their packaging requirements change frequently as they release new products, enter new markets, and do frequent pricing experimentations and the inadequacy of the existing billing systems then comes under a microscope. This forces the enterprises to look for upstream billing vendors but that introduces another complexity (these systems don’t understand the self-serve channel). Consequently, the enterprises are forced to maintain two sets of systems – one for self-serve and another for sales-led which makes expansion (from self-serve to sales-led) or contraction (sales-led to self-serve) an extremely painful proposition. 

So, what’s the answer to this puzzle?

First, the product catalog needs to be enterprise-friendly from day 1. 

Second, the CPQ and Billing boundaries need to come down, and they need to be together to facilitate the land-and-expand nature of the SaaS businesses.

Third, this integrated platform need to be API-centric so that it can serve the new omnichannel reality of the B2B Enterprises – self-serve, sales-led, partners, and now even marketplaces (there could be 2 versions of this: one, where the B2B enterprise creates its own marketplace and the other where it’s products are sold on an another marketplace).

This is what we are building at MonetizeNow.