Software sales commonly include professional services such as consulting, integration, implementation, and customization in their deals. Under ASC 606 revenue recognition standards, services that have value as standalone items are considered separate performance obligations. Integration, implementation, and customization have little value without the software in question, so in most cases, these services won’t be a separate performance obligation.
Software companies with service offerings must use Fair Value Pricing (FVP) for revenue allocation between different subscription and service components when sold in a bundle. This ASC 606 requirement presents several challenges for our clients who use NetSuite for revenue recognition while managing their project management business processes outside of NetSuite.
Today, we will explore the options available when using NetSuite Sales Orders to record software sales and OpenAir to manage and projects.
Luckily, OpenAir integrates revenue recognition rules and recognition transactions to NetSuite for use in Advanced Revenue Management. The following OpenAir Revenue Recognition Rules are currently supported by NetSuite’s Advanced Revenue Management:
- As Billed
- Fixed Amount on Date or Milestone
- Fixed Amount % Complete
- % Complete
- Incurred vs. Forecast
- Time Project
WORKFLOW
The first step in sending OpenAir Revenue Recognition Transactions to NetSuite is to configure the OpenAir Advanced Revenue Management plugin in NetSuite. This process must only be completed once and is valid for all Revenue Recognition Rules supported by Advanced Revenue Management.
Next, configure a Revenue Recognition Rule in OpenAir which is supported by Advanced Revenue Management. Set up the mappings for the rule on the Mappings page in NS Connector. Mappings can be configured in either the old or new NS Connector UI.
The standard NetSuite OpenAir integration, the Standard Connector creates a custom record in NetSuite and creates Revenue Recognition Transactions for each line in the rule. Advanced Revenue Management is triggered in NetSuite and the Connector creates a Revenue Event and a custom record in NetSuite from the Transaction. The custom record says which rule created the Revenue Transaction, and also tells Advanced Revenue Management how to account for the Revenue Event.
Advanced Revenue Management then uses the Revenue Events to create NetSuite Revenue Elements. A Revenue Element is created for each Revenue Recognition Transaction which is then used by Advanced Revenue Management to create Revenue Plans.
ADDITIONAL AUTOMATION
The standard NetSuite – OpenAir integration does a great job of setting the foundation for recognizing revenue for projects using NetSuite ARM. This process does not meet the minimum requirements needed by SAAS clients when revenue needs to be allocated between software and services within the same performance obligation. The problem that presents itself is as follows:
- Sofware subscriptions are sold and recorded on the sales order line item (typically these sales orders are integrated from Salesforce.com).
- The sales order creates a revenue element for each line item and a revenue arrangement for the entire sales order. However, this sales order does NOT contain the information needed to recognize revenue for the associated professional services.
- The NetSuite – OpenAir integration creates revenue elements and a revenue arrangement for professional services.
- Because the software and professional services are on two separate revenue arrangements, you are not able to allocate the revenue based on FVP.
In order to properly allocate revenue between software and professional services, NetSuite users can use one of the following approaches:
- Manually merge the two revenue arrangements and trigger the allocation. This is a fairly easy process, but may not be a viable approach depending on your volume.
- Automate the merge of the revenue arrangements based on pre-defined logic.
- Scripting is required for this approach.
- Full automation will require a very detailed analysis of the business requirements and logic needed to automate this merging. The more complex the requirements, the riskier the implementation.
