APPENDIX B: NetSuite Data Model

When looking at NetSuite, it is worth noting that NetSuite supports a wide range of businesses that sell all kinds of goods and services. The underlying data model in NetSuite is vast and much of it is not relevant to supporting the quote-to-cash process for a B2B SaaS company. In order to understand how we should integrate with NetSuite it is worth going through some different aspects of its model.

One of the key processes in NetSuite is the Sales Order Process. At a high level this can be depicted as:

• In NetSuite, a Sales Order is linked to a Customer who is purchasing products or services. 
• Items (whether inventory, service, or other types) are included in sales orders, and the Item Type categorizes them (inventory items, non-inventory, service items, etc.)
• The Fulfilment process happens after a sales order is approved. This involves fulfilling (shipping or delivering) the items in the sales order. Once the fulfilment is completed, the Invoice is generated
• After fulfilment, Invoices are generated in NetSuite to bill the customer for the delivered items or services. The Payment process follows, reflecting when the customer pays the outstanding invoice.
• NetSuite uses Return Authorizations to track customer returns, and once the return is processed, a Credit Memo is issued to adjust the customer’s account, refunding or crediting them for the returned goods.

However, for B2B SaaS companies, there are no hard goods and so no real inventory, as such.

• For more complex sales processes, like those involving subscriptions or service contracts, NetSuite uses billing schedules or revenue recognition schedules that may trigger invoices over time.
• Sales orders can also include non-inventory items or service items, which might not affect Inventory but still go through the sales order, fulfilment, and invoicing steps. These item types should be part of the broader Item Type object.

For recurring services such as a SaaS subscription, NetSuite has a Billing Schedule object which can be configured on a per item basis and is associated with a sales order.

Types of billing schedules include:

• Standard Billing Schedule: Bills at regular intervals (e.g., monthly or quarterly).
• Milestone Billing Schedule: Bills based on completion of project or service milestones.
• Fixed Amount Schedule: Bills a specific amount at each interval.
• Percent-Complete Schedule: Bills based on the completion percentage of a project or service.

When sales orders are used, line items for each of the items covered by the billing schedule are automatically placed on each of the invoices that get automatically created.

For companies that have purchased the Advanced Revenue Management (ARM) module, a Revenue Recognition Schedule is also introduced which allows you to specify how revenue should be recognised for each item or item type. This object manages the timing of revenue recognition for items or services sold, based on the specific recognition rules or templates applied. This schedule breaks down the revenue associated with a transaction (such as a sales order or invoice) into periods, ensuring that revenue is recognized in compliance with your revenue recognition policy, rather than all at once.

Key Fields of the Revenue Recognition Schedule Object:

• Name: The name of the revenue recognition schedule.
• Total Amount: The total amount of revenue to be recognized.
• Start Date: The date when revenue recognition begins.
• End Date: The date when revenue recognition ends.
• Recognition Method: Specifies how revenue will be recognized (e.g., straight-line over time, percentage complete).
• Period: Defines the periods over which revenue is recognized (e.g., monthly, quarterly).
• Recognized Amount: The portion of the revenue already recognized.
• Unrecognized Amount: The portion of revenue that has not yet been recognized.
• Deferred Revenue: Links to the deferred revenue account where revenue is stored before it’s recognized.

Key connections:

• Revenue recognition schedules are often tied to Sales Orders, particularly in cases where the order includes items or services that are fulfilled over time. Once the sales order is fulfilled, the schedule dictates when revenue is recognized based on the service or product’s delivery over time.
• Invoices generate revenue recognition schedules when items or services are billed. In situations where invoicing happens upfront (such as for a year-long subscription), the Revenue Recognition Schedule will spread the revenue recognition over the contract period, even though the invoice is generated at the beginning.
• Certain Items (such as subscriptions or services) may have revenue recognition templates applied at the Item level. When these items are added to a sales order or invoice, the system automatically applies a Revenue Recognition Schedule based on the item’s recognition rules.
• A Revenue Recognition Template is applied to items or sales orders to define the rules and parameters for revenue recognition. The template is used to create the Revenue Recognition Schedule, which then dictates how revenue will be recognized for that transaction.
• For companies using SuiteBilling, Subscriptions often generate Revenue Recognition Schedules. The subscription’s billing schedule defines when invoices are sent, while the Revenue Recognition Schedule controls how revenue is recognized over the term of the subscription.
• When revenue is billed but not yet recognized (such as for prepaid services or subscriptions), the amount is recorded as Deferred Revenue. The Revenue Recognition Schedule moves revenue from the deferred revenue account to the revenue account as the service or product is delivered over time.

Types of revenue recognition schedules include:

• Time-Based Recognition (Straight-Line): Recognizes revenue evenly over a specified period (e.g., a subscription over 12 months).
• Milestone-Based Recognition: Recognizes revenue when specific milestones or conditions are met (common for project-based businesses).
• Event-Based Recognition: Recognizes revenue when a specific event occurs, such as the delivery of goods or fulfilment of a service.

Sales Orders

So far, sales orders are at the center of everything and often finance teams we work with see them that way. But here’s the thing - for B2B SaaS use cases, NetSuite will work fine without them. And furthermore, because NetSuite has a very flexible model (a lot of objects connect to each other), it’s not hard to take them out, as follows:

This works because Items can be directly associated with Billing Schedules. So items (of non-inventory type software subscription), for example, may have a recurring monthly billing schedule and the existence of this will mean that after the first invoice is created for the recurring item (the invoice links to the customer), subsequent invoices will automatically be created.

And this will work whether or not they have SuiteBilling and whether or not they have ARM (although, if they don't have ARM, they have to do revenue recognition manually through journal entries).

Why have Sales Orders?

The primary motivation for using Sales Orders in B2B SaaS use cases is a desire for NetSuite to be the single source of truth for what has been agreed with the customer and for reporting requirements in support of that assumption. The secondary motivation is that NetSuite is often configured this way and its users trained to work with them.

However, nearly all companies use Salesforce to support their sales teams and most use the CPQ plugin which creates Sales Orders in Salesforce. Relying on the orders being in NetSuite creates a burden of 2-way synchronization between the customer order in Salesforce and the same customer order in NetSuite which is difficult to maintain.

Furthermore, as usage-based pricing becomes more common in B2B SaaS companies the product catalog that is maintained in the front office system (Salesforce) and the back office system (NetSuite) may diverge. Consider Snowflake, for example. Pricing for Snowflake changes based on several dimensions including cloud provider, cloud provider region and flavor of Snowflake. The front office system needs to know about these prices to support the quotation process but does the back office system need the same granularity of data?  Often not as the product would be accounted for at a lower level of granularity. This creates a divergence in the product catalog representation in the front office system and the back office system which means that sales orders in the back office (NetSuite) will be based on different product catalogs (items) than the sales order in Salesforce and can no longer be counted on as a reliable single source of truth.