This article is written for Revenue Accountants, Controllers, and CFOs who are considering implementing NetSuite’s Advanced Revenue Management (“ARM”) module and seek clarity around its feature set and functionality. It is the second article in this series dedicated to revenue recognition. The earlier article can be found here: NetSuite Revenue Recognition Fundamentals: A Clear Framework for Getting it Right.
TL;DR Summary
ARM is a multilayered system that provides structure and automation for even the most complex Revenue Recognition situations, and its intricacies can be confusing. Familiarity with ARM’s concepts, record types, and features will help you design your revenue recognition environment to best fit your business without friction between operations and accounting. See the video below in which Prolecto Senior Analyst Heidi Jensen and I discuss the ARM architecture and some of its advanced capabilities.
Introduction
In my previous article in this series, NetSuite Revenue Recognition Fundamentals: A Clear Framework for Getting it Right, I discussed some common scenarios subject to revenue recognition requirements and argued that ARM is not always necessary, especially when customers pay in advance of shipment and performance obligations can be represented by native item fulfillments. (“Performance Obligations” are the key factors that dictate revenue timing under ASC 606 and IFRS 15).
In this article, I will clarify ARM’s key record structure and discuss some of its more advanced built-in capabilities, highlighting situations for which ARM is ideally suited. In my next article, I will present key success strategies for implementing Revenue solutions successfully and discuss how to avoid common pitfalls.
Prolecto’s Thought Leadership
For nearly two decades, Prolecto has been trusted by our clients to help them optimize NetSuite to tackle thorny business problems. We recognize that choosing a software solution like ARM can’t solve problems without equal importance and primacy given to understanding the business requirements. Revenue Recognition is not one-size-fits-all, and over time, we’ve developed the following accelerator templates that emerged from our pursuit of the right solution for our clients.
Prolecto Revenue Recognition and Cost Amortization
The Prolecto Customer Deposits Generator
For those that are interested in previous articles on Revenue Recognition concepts, see the following:
- 2013: How NetSuite Relieves Quickbooks Revenue Recognition Pain
- 2013: Automate NetSuite Cost Amortization via Revenue Recognition
- 2019: Take Control: A Simplified Approach to NetSuite Revenue Recognition and Cost Amortization
- 2023: Simplified Revenue Recognition in NetSuite for Businesses with Recurring Services
- 2025: Cut NetSuite Complexity: Deposits and Payments Instead of ARM and Proprietary Portals
Understand the Key Structures of NetSuite’s ARM module
ARM, as a system for revenue generation, can be viewed as a somewhat parallel system to the Sales Order transaction flow. Revenue Arrangements parallel Sales Order Headers, Revenue Elements parallel Sales Order Lines, and Revenue Plans parallel Invoice Lines. Below are descriptions of the basic records that ARM introduces and their functionality.
Revenue Rules: These are static records that drive revenue recognition behavior. These can be thought of as similar to Depreciation Method records in FAM (Fixed Asset Management), or Amortization Templates for expense amortization. The Rules determine a variety of settings, including what event (such as an item fulfillment) should trigger Revenue Recognition, whether Revenue is recognized on a straight-line basis or under a different pattern, and where to source the start and end dates from. Items subject to Rev Rec need to be tagged with a “rule” to define the patterns for recognizing Revenue for each item.
Revenue Arrangements: Parallel to Sales Order or Estimate headers. These are non-posting transactions that generally are 1:1 with a source sale transaction (which can be an Estimate, Sales Order, Invoice, or even Projects or Custom records). These represent staging records for a discrete group of items against which Revenue will be recognized, similar to how a Sales Order represents a discrete group of items against which billing (invoices) occurs.
Revenue Elements: These records parallel Sales Order lines in terms of structure, and are linked to the relevant source transaction lines, which can be Sales Order lines, but also can be Estimate Lines, Invoice Lines, or custom record structures, depending on the source transaction that triggered the Revenue Arrangement creation.
Revenue Plans: These records loosely parallel invoice lines in that they are the crucial, actionable outcomes of the Revenue Elements and represent the revenue that will post. Note, however, that Plans (like Arrangements and Elements) are non-posting. They set the stage for the Revenue Recognition Journals that post automatically or via user instruction, depending on the ARM configuration. Note that ARM produces two “Plans” per element, a “Forecast” and an “Actual” plan. Forecast plans (as implied) are intended to allow forecasting revenue using rules different from the “actual” plans and can be useful for comparison and decision-making, but are beyond the scope of this article.
Revenue Recognition Journals: The final step of Revenue Recognition. These can be automatically generated or on demand, depending on the ARM configuration, and can be created with summarized amounts or in detail.
These Journals post entries that (generally) Debit Deferred Revenue and Credit Revenue, reflecting an initial assumption that revenue is recognized in arrears (i.e., after invoicing). Then, if needed, a second type of Journal Entry will be automatically generated, debiting Unbilled Receivable and crediting Deferred Revenue for any Revenue Recognition element whose source item has not yet been invoiced (meaning, where Revenue needs to be recognized in advance of billing).
Divergent Revenue and Billing Narratives Drive NetSuite’s Revenue Complexity
When reflecting on the above, the obvious question that comes to mind is: “Why all these record structures?” Why is there a need for a parallel record structure when, at first glance, all of the relevant information could easily be captured on the sales transaction lines themselves? Items, Rates, and Sales Amount are all on sales transaction lines, and simple start and end date fields would be simple to add. NetSuite is certainly powerful enough to generate revenue transactions from Sales Order lines, just as invoices and item fulfillments are. What purpose, then, does the entire ARM structure serve?
The answer to this question gets to the crux of Revenue Recognition requirements.
Revenue Recognition recognizes that a company may earn revenue at a different timing cadence than when it collects payment from its customers. Similarly, there can be scenarios in which the entire revenue narrative needs to be expressed differently from the billing narrative.
A common example of this is situations subject to “Fair Value Allocation” rules. For billing purposes, the sales price of individual products or services may be expressed one way, perhaps with certain items at steep discounts (or even given away for free) and other items at prices marked up to even out the discounts and achieve the margins needed. Yet, for revenue purposes, items that are part of a “package” may need to be grouped together and recognized in tandem, with an allocation to spread the revenue proportionately across the items.
The allocation method under ASC606 is known as the “Stand-alone Selling Price” (SSP) or “Fair Value” method, which states (basically) that one first needs to determine what the selling price would be if each component were sold separately (hence, “stand-alone”), and then the relative proportions of each SSP to the total SSP of a related group of products/services is used as the percentage attributable to overall actual price of the sale.
Consider another scenario that requires a Revenue narrative that diverges from the billing narrative: For billing purposes, a Sales Order may have meaning as a collection of products to fulfill together as one deliverable, yet for Revenue purposes, there may be other Sales Orders that are deemed part of the same “deal” and therefore Revenue metrics need to be calculated across more than one Sales Order. Likewise, there may be Credit Memos that were created from invoices, yet are not directly linked back to the source Sales Orders. For billing purposes, this is OK, but Revenue Rules may need to see the net Revenue across the entire “deal” and recognize revenue accordingly.
ARM’s Value Propositions: Revenue Allocation and Merging Arrangements
To handle the above scenarios, ARM has advanced features that can reflect the Revenue Narrative even when it differs from the Billing Narrative, while maintaining linkages back to the billing transactions. To support this, the revenue structures need to be distinct from the billing and fulfillment structures. Accordingly, this required flexibility in running different transaction narratives is what I consider the main reason ARM needs a full record system for Arrangements, Elements, and Plans.
Revenue Allocation
ARM has additional features to handle fair-value-based allocations and custom formulas to capture the sometimes very nuanced requirements for grouping items for allocation, and can even handle thresholds that allow discounts within each item or item group without triggering fair-value allocation.
This feature, called Revenue Allocation, includes the ability to create price lists that hold fair-value “stand-alone” selling prices for items (as distinct from actual selling prices). The formulas for the supporting calculations can be quite complicated and are supported by ARM, but require careful attention to ensure they produce the intended results. This is where planning and thorough testing are crucial.
Contract Merging
ARM also includes a “Merge Revenue Arrangements” feature, which can unify the Revenue Narrative across multiple billing-oriented source transactions into a single set of Revenue components to be recognized in tandem. This solves the second type of scenario described earlier, where the components of a single unit or package of items need to be recognized together, even though they are spread across more than one Sales Order.
Often, both Fair Value allocation and Contract Merging are needed to work together, where the fair value allocation must span items that appear in more than one Sales transaction.
Video: ARM Primer and Capabilities
I met with Heidi Jensen for a wide-ranging conversation exploring ARM’s strengths, best practices for implementations, and the risks companies should seek to avoid. Please see the video below of our conversation, which lays the foundation for understanding ARM. To skip to advanced ARM sections, use the timestamps below.
- 00:00 – Introduction: ARM & ASC 606 Context
- 01:30 – Why ARM Became Essential in NetSuite
- 03:20 – ARM vs Billing: Revenue vs AR Timing
- 04:34 – ARM Architecture: Arrangements, Elements, Plans
- 07:26 – Why ARM Adds Value and Complexity
- 09:20 – Merging Transactions & Contract Revenue
- 10:12 – Fair Value (SSP) Allocation Explained
- 14:06 – Allocation Across Bundled Deals
- 15:25 – Allocation Groups & Price Ranges
- 16:18 – Continuous Recalculation & ARM Power
- 18:00 – Key Takeaways & Closing
(function () {
const iframe = document.getElementById(‘ytplayer’);
const base = “https://www.youtube-nocookie.com/embed/CP3GtiZrrvY?rel=0&modestbranding=1”;
document.querySelectorAll(‘a[data-start]’).forEach(a => {
a.addEventListener(‘click’, function (e) {
e.preventDefault();
const start = this.getAttribute(‘data-start’);
iframe.src = base + “&start=” + encodeURIComponent(start) + “&autoplay=1”;
});
});
})();
Conclusion: Be Informed, Plan, and Execute
Revenue measurement is foundational to a company’s financials, and getting it right is often the Controller’s biggest worry.
The Accounting Practice at Prolecto consists of certified accounting professionals with decades of NetSuite experience. We work alongside our clients’ accounting teams to help them create an attack plan for Revenue, properly shaping the NetSuite environment to produce revenue recognition that can be trusted.
If this article resonates, consider subscribing to receive notifications for new posts. If you are navigating a Revenue Recognition situation and want expert guidance, let’s have a conversation.
