Reference Architecture

The following diagram represents the optimal architecture for the quote-to-cash stack of a B2B SaaS company with a significant Sales-led motion and usage-based components in their pricing.

m3ter reference architecture diagram showing processes
m3ter reference architecture diagram showing processes

Business Processes

This reference architecture is based on a set of business processes.

  • The process model, from left to right, starts with a pipeline opportunity. 
  • In a sales-led motion, once an opportunity advances past the technical validation phase and requires pricing, a quote is issued. The quotation process can be iterative in support of a negotiation with a customer and each iteration may optionally be reviewed by a deal-desk responsible for monitoring deal quality. 
  • When a quote is accepted by both parties a contract is written and an order created. 
  • The signature of the contract results in an order being activated indicating that the software service(s) may now be provisioned. Software provisioning can vary in complexity  but companies generally aim to make it as simple as possible  to remove friction and manual processing. 
  • When software is provisioned and is being used by the customer that creates the need for invoicing. A company’s invoicing process is dependent on their pricing and charging models and can vary significantly by company. 
  • When invoices are issued to customers a collection process is initiated and in parallel the finance teams book the revenue, file the taxes and allocate the revenue to the appropriate accounts in the general ledger system. 
  • Finally, when the initial term or allowance associated with an order (or contract) is expired a renewal is triggered.

See the section on Business Processes and Teams for more details.

Affected Teams

The extraordinary thing about the quote-to-cash process is how it spans so much of the organization. The sales order process is executed by the Sales team, the fulfillment process by Product and Engineering, the invoicing, collection and revenue recognition by Finance, and renewals by Customer Success. Sometimes the Sales team is re-engaged to negotiate renewals making the process flow circular. See the section on Business Processes and Teams for more details.

Systems

Processes are supported by Systems. Sales teams everywhere use Customer Relationship Management (CRM) systems to manage pipelines and many use Configure Price Quote (CPQ) systems to manage the quotation and order process. B2B SaaS is typically contracted using an Order Form which is a document that gets designed and distributed using a document management system (e.g. Docusign) integrated with the CRM/CPQ. A common source of internal friction arises when the terms that are in the signed document are not what is captured in the order record in the CPQ system. 

The fulfillment process for a B2B SaaS company is usually much simpler than for other types of business as nothing in the order needs to get shipped or posted. Rather, the customer needs to be given appropriate levels of access and this is something that can usually be automated and access controlled - provisioning teams just require a system that alerts them to do the provisioning and when to revoke access. 

Invoicing is done by the revenue operations and/or Finance operations teams and is most usually done using the accounting system or Enterprise Resource Planning (ERP) system. When line items are added to an invoice (from a sales order or a metering system) tax is added to the invoice. Tax is a specialist area and most companies use a solution from vendors such as Vertex or Avalara that are well integrated with most ERP platforms. The process of issuing invoices, accepting payments and collections (often requiring additional dunning processes) is managed in the ERP. At the end of each billing period nearly all companies have to execute, at a high level, the month end closing process (see The Month-end Close for a detailed breakdown of what is involved) which allows them to complete their finance reporting and ensures they are compliant with regulatory requirements.

Although m3ter supports many different systems we are optimised for companies that use Salesforce for their sales teams and NetSuite for their finance teams.

Cross-functional System Components

There are 4 key systems that are often overlooked when describing the quote-to-cash stack:

  1. Metering and Rating:- the metering and rating system is what enables your quote-to-cash stack to automate complex usage data processing and rating requirements at scale and on a continuous basis. It sits in the middle of your stack and interfaces with most of the other components in order to achieve this.
  2. Entitlements Management:- an entitlement management system increases in importance as B2B software companies grow and offer more features and products. The right of a customer to access features and products becomes more difficult with usage-pricing models because entitlement is not just about a binary on/off access right, but also about a right to access an amount of usage.
  3. Integrations Platform:- The architecture consists of a collection of systems which need to exchange data with one another and this requires an integration system or an Integration Platform as a Service (iPaaS). Depending on the business process being supported, the exchange of information can range from synchronous transaction-based (e.g. when an order is complete, send the details to the metering and rating service) to asynchronous batch-based (e.g. submitting large volumes of usage).
  4. Reporting & Analytics:- The reference architecture consists of a collection of systems each of which becomes the system of record for one or more data sets. Therefore, in order to develop a complete end-to-end view of a specific business data should be exported from each of the key systems and combined in a single reporting and analytics stack.

See the section called Systems for more details.

Datasets

As a company’s pricing gets more and more complicated, the process of handing off what has been agreed with a customer to the team doing the invoicing for that customer often breaks down. The cause for this is always the same - bad data. SMB companies with usage-based pricing typically use spreadsheets to store the commercial terms agreed with customers because the subscription management solutions targeted at this segment don’t support a high level of complexity. Midsize to enterprise companies (m3ter’s typical customer) have usually attempted to fix this issue with (expensive) in-house tooling but typically face challenges with data in the sales system being different from that in the finance system. Integration platforms (iPaaS) exist to try and solve this and for simple subscriptions can work well but for more complex pricing they are not sufficient. An important aspect of the reference architecture is to identify the optimal system of record for a specific dataset and recommend how data should flow between systems. See the section called Data for more details.