Data

There are several reasons we need to include the data model layer in the reference architecture:

1. In a multi-system architecture it is vital that the underlying data models complement each other (= work well together) and data can move seamlessly through the stack
2. When we break down processes into their sub-processes, often those sub-processes are operating on one or two key objects and therefore, in many ways, it is the data layer that validates the process layer in the overall reference architecture

There are appendices which go into the detail of the model behind each key system. Here we will make a recommendation on the best models from each of them and how they should work together.

Reference Data Model

NB. The thicker, darker lines in the diagram above show the key objects in each area and how they map to corresponding objects in another.

For the purposes of supporting the quote-to-cash process(es) the key objects in this include:

Sales Order Management

Account

This object uniquely identifies the customer. Managing the customer record across the full quote-to-cash stack is a problem that every company is faced with when implementing their quote-to-cash stack and there are several different patterns that can be applied depending on the primary and secondary sales motions. Each system in the quote-to-cash stack has a slightly different need around the customer attributes required to fulfil its task which is what complicates the synchronisation design pattern. Furthermore, customers can have complex organisation designs and often need to be represented over multiple hierarchies across the stack.

Opportunity

This is the key object used to facilitate the sales process with an account or customer. Companies receive leads and when those leads are initially qualified they are converted into opportunities. Opportunities have stages associated with them which is what creates the workflow associated with pipeline management. The stages an opportunity goes through are usually highly configurable and reflects a company's specific sales approach.

Quote

When an opportunity advances enough in the sales process, at some point the customer requires a formal quote. This process is usually facilitated well by the CRM system but may require an additional CPQ module to be installed. There is usually some back and forth with the customer and internal deal approval teams around this process which should be aided by the system. A quote typically contains line items representing the different product or service SKUs the end customer is interested in purchasing. The line items are usually generated from the product catalog and pricing managed in the front office system.

Order

When a quote is agreed by the end customer it is converted into an order. An order object is quite similar in structure to a quote object but has some key differences. Firstly, it is usually associated with a contract. Secondly the date fields on an order reflect the duration of an agreement with the customer whereas a quote requires additional date fields to determine how long it will remain valid for.

Contract

This object is usually created at the same time as an order (when a quote is converted) and contains the key variable elements that are put in the electronic contract or order form which the customer is required to sign.

Product Usage

The key data the customer success (and/or product & engineering) team(s) need to know once a customer order has been activated, is what features or products they need to provide access to and for how long.

Entitlement

This object is usually created once the order is activated and many front office systems (such as Salesforce) support entitlements. This record is used by product & engineering to determine which level of access to provide to different product(s) and feature(s).

Usage

Usage is generated when customers start using products. Often usage can be in the form of logs generated by the product and underlying product resources. The key things to anticipate are scale and flexibility in format, aggregation logic and mediation as products evolve.

Metering & Rating

There is typically a lot going on in the metering and rating system and, because of the role it plays sitting in between the other systems, there is a lot of overlap of key objects. The use of these objects is not particularly altered by whether or not a sales-led or product-led motion is deployed (NB. when marketplaces are used in support of product-led motions, an important interface between the metering system and marketplace is required - see Business Process Architectures). 

Assuming we are using m3ter, as the metering & rating platform of choice, the key objects are as follows:

Accounting & Billing

• Account:- usually populated directly from the front office system this is the key entity associated with all usage that is submitted and with all bill line items that are pushed to the back office or invoicing system.
• Contract:- This is an optional object that can be used for improving the reporting capabilities of the metering and rating solution so that it can more effectively report on total contract values.
• AccountPlan:- This binds pricing to an account for a period of time for a specific product.
• Bill:- This is an internal representation of an invoice but differs in that the metering and rating system should not send invoices, rather it provides outputs to the invoicing system and the Bill object is used for better navigation and visualisation within the metering and rating system.
• Line Item:- There is usually a line item for each product or pricing SKU created in a given billing period and these line items are pushed to the invoicing system. Line items can be of lots of different types reflecting the different pricing and charging models that are being used.
• Balance:- Where allowance or credit models are being used, the metering and rating system is where these should be drawn down and balances managed (why? Because often rating rules are complex and need to be applied close to where aggregation rules are applied).
• Prepayment:- When customers prepay in cash for a period of time, again the drawdown and management of this prepayment needs to be managed in the metering and rating system.

Product & Pricing

• Meter:- reflects the schema definition of usage data and usually a single meter maps to a single data source type.
• Aggregation:- used to define functions (like database group functions) which are applied to meters to convert incoming usage data into suitable billable events.
• Pricing:- used to encode sophisticated pricing logic that can be applied on a per product and / or per customer basis.
• Plan:- used to group pricing on a per product basis.
• Product:- used to group bill line items into logical products and map to the downstream invoicing or ERP system.

Billing & Finance

All mid-size and larger B2B SaaS companies will have a back office system to support their billing and finance needs. As previously stated in this document (see Systems), we believe this is where invoicing & revenue recognition should live. For the purposes of this section of this document, we are not diving deep on important functions such as management of accounts payable, general ledger and cash flow management.

Invoicing

• Customer:- this should map to the account created in the front office system but to support invoicing often more data is required which is not required by the order management process. Most companies try to capture the full data set in the front office system and sync it to the back office and for companies that don’t do this then often manual entry is required.
• Invoice:- this is the core object for management of accounts receivable as it is the mechanism a company uses to summarise the value of goods and services it has provided and to charge their customers. 
• Item:- invoices line items are based on items or products. These items are created based on the version of the product catalog that is managed in the back office system. It may differ from the product catalog that is represented by the front office system.

Revenue Recognition

• Revenue Recognition Rule:- this determines how revenue can be recognised and these rules are defined at an item level which means that invoice line items that are mapped correctly to items will be automatically treated in terms of revenue recognition without manual work required.
• Revenue:- this is the income account in which revenue that can be recognised immediately is placed by the appropriate revenue recognition rule.
• Deferred Revenue:- this is the account where invoiced amounts that cannot yet be recognised are placed for future processing.

Exclusions (from the Reference Data Model)

We have not covered the following topics in the above data model:

• Integrations Platform-as-a-Service:- there is a strong need to have customisation in the integrations which tie different systems together and this allows the reference architecture to better meet the needs of any B2B SaaS company. This functionality will be offered by the metering and rating providers over time.
• Entitlement Management:- we have included the entitlement object in the above data model however for larger companies entitlement management is a more complex topic. This functionality will be offered by the metering and rating providers over time.
• Payments:- most invoicing and ERP platforms support multiple payment gateways provided by different payment providers such as Stripe, Paddle, Paypal, GoCardless etc. The payment gateway is used to accept payments directly from customers and lodge these payments into your bank account.
• Taxation:- similarly, most invoicing and ERP platforms support different taxation solution providers such as Avalara and Vertex. These solutions allow you to apply complex taxation rules to invoice line items that are passed into the invoicing solution from the metering and rating system.