Systems

In this section we drill down deeper into some of the key systems that make up the quote-to-cash framework and specifically how m3ter fits within that context.

The Horizontal Axis: Systems Supporting Business Processes

CRM/CPQ (usually Salesforce)

On the left side of the diagram we start with the CRM/ CPQ system where deals typically originate. Most medium to large B2B SaaS companies implement order management (over simple opportunity management - see Appendix A) as this facilitates a thorough understanding of what services the customer should be receiving and how much they have agreed to pay. It also better supports internal functions such as a deal desk as order management typically supports workflows, e.g deal review, and approval steps natively. In order to do this, the front office system needs to have enough visibility of the product catalog and pricing to support the quoting and ordering process and for many customers this is where they will manage the master data set. More detail on Salesforce and how it should be set up can be found in Appendix A.

Metering & Rating

In order for the metering & rating system to work, both account data and order data need to flow into it so that it can do the complex calculations based on what has been agreed with the customer. In rare cases, a customer may opt not to use their front office system for master product & pricing management and in these cases m3ter can be used as an alternative or it can ingest the pricing from an alternative service. The rating process can be run on a continuous basis which is important for both internal and customer reporting so that a customer, for example, can tell at any point in time what their current bill is running at or a finance team can see how their revenue is building over a period.

ERP

To the right of the horizontal axis is the back office system or ERP. This is the software typically used by a finance team to handle invoicing, revenue recognition, taxation and the reconciliation of accounts. ERP systems usually struggle with complex bill calculations and large data sets and this is what creates the initial need for a metering and rating system. The metering and rating platform handles all of the complex transactions and writes line items to invoices in the ERP allowing it to execute the billing function and issue invoices with the correct amounts.

Our recommendation is that invoicing should be done in the finance system (and not the metering and rating system). There are several reasons for this:

1. It is nearly always executed by the finance team and it’s better to have them operating with a single system where possible for their primary finance processes.
2. Revenue recognition and the allocation of billed amounts to income or liability accounts as appropriate is fully dependent on the invoicing process and if you couple these processes closely in one system you can fully automate and reduce manual effort.
3. Most ERPs have a strong invoicing feature that supports configurable workflows and have strong out-of-the-box integrations with payment and tax providers. Larger companies will discover that invoicing in itself requires a highly configurable solution to meet their customers demands and typically only the richer invoicing solutions (as part of the ERP solutions) meet these needs.

The one exception to this is Salesforce Revenue Cloud which aims to replicate the above characteristics in the Salesforce platform (why not? NetSuite has a full CRM and order management capability).

The Vertical Axis: Systems Supporting Engineering Processes

Product Usage

Medium to large B2B SaaS companies usually have more than one product which generates different usage data formats that convert in a highly variable way to product SKUs which need to be billed. Neither Sales CRM/CPQ platforms nor ERP or Finance platforms handle usage well or at scale - they are simply not intended for it. Usage data should be routed to a specialist metering and rating service for the purposes of attaching value and billing. Often the same data pipelines that are used to generate data for observability purposes can be re-used for this purpose also.

Metering & Rating

The metering and rating system is at the center of both the horizontal and vertical axes. To date, companies that bill their customers using anything but simple subscriptions have either used spreadsheets (which don’t scale well) or have had to build the metering and rating capability themselves. Many metering & rating specialists have emerged over recent years to meet this need. The key aspects of a good solution are:

1. Flexibility and scale around the ability to ingest and transform usage data in a variety of ways and formats.
2. Usage data should be persisted at the level it is ingested - this is vital for error recovery, audit & compliance and sophisticated analytics such as forecasting.
3. Ability to handle sophisticated pricing models so that the rating process is entirely automated. When shortcuts are taken here it leads to too much manual exception processing during each billing cycle.
4. Support for a full range of pricing models including one off purchases, subscriptions and complex usage (concurrently) as well as a full set of charging models such as pay-as-you-go, prepay and credit based models. This means that subscription management and usage-based pricing can be supported by the same solution.
5. It should have native mature integrations with the other systems in the reference architecture and avoid duplication of feature or function.

Business Intelligence & Reporting

Because various important data sets are spread across multiple systems, in order to develop a single end-to-end view of a business, it is recommended that a separate reporting stack is created. These stacks usually consist of data engineering solutions that facilitate capturing and transformation of the source data, storage in the form of a data warehouse and a front end reporting and dashboarding tool so that different teams can build the reporting they need to operate their business units. There are several motivations for creating a separate reporting stack:

1. No one system is the system of record for all of the data:- The reference architecture is made up of multiple systems and each of them is the system of record for a subset of the overall data. In order to combine each of these data sets to create a 360 degree view of the business, the data first needs to be exported to another repository.
2. Different teams need access to different views of data across the systems:- and it is not practical to open up access to all of the systems to everyone in the organisation. Using a separate reporting stack, access can be provided and controlled to all of the data sets without having to buy additional seats for the relevant systems. It’s a cheaper and more efficient way of giving different constituents what they need.
3. External customers may also need access to reporting:- often end customers need access to reporting dashboards too - particularly to query previous bills and understand current ones. It is not advisable to open up access to your quote-to-cash stack in this way and it is recommended to create an external customer reporting system that leverages your reporting stack.