ASC 606 is simple to state and hard to run. The standard (and its international twin, IFRS 15) says revenue follows a five-step model: identify the contract, identify the performance obligations inside it, determine the transaction price, allocate that price across the obligations, and recognize revenue as each obligation is satisfied. Any controller can recite it. Applying it to 3,000 contracts a month, with bundled deliverables, mid-term changes, and auditors watching, is a different job.
NetSuite’s answer is Advanced Revenue Management, usually shortened to ARM. This article explains what it is, how it moves a sale from contract to general ledger, the setup decisions that determine whether you love it, and the mistakes we see when it’s rushed.
Two Editions, One Framework
Oracle ships ARM in two pieces. Advanced Revenue Management (Essentials) is the core: it automates revenue deferral, recognition, reclassification, forecasting, and auditing through a rule-based framework, and Oracle documents it as compliant with ASC 606. Advanced Revenue Management (Revenue Allocation) is the add-on for multi-element deals, where the price a customer paid for a bundle has to be split across its components in proportion to their standalone values. It adds fair value price lists and allocation formulas on top of Essentials.
A services firm billing fixed-fee projects and a SaaS company selling single subscriptions can often live on Essentials. A company selling software plus hardware plus support in one contract, at a bundle discount, needs Revenue Allocation, because the allocation step of ASC 606 is exactly what it automates.
The Records That Do the Work
Four record types carry the logic, and understanding them makes everything else in ARM legible.
Revenue arrangements are non-posting transactions that capture the performance obligations in a deal. NetSuite creates them automatically from revenue sources such as approved sales orders, and arrangements from multiple sources can be consolidated when one contract spans several transactions.
Revenue elements sit inside an arrangement, one per source line. Each element represents a single performance obligation with its own amount, dates, and recognition treatment.
Revenue recognition rules define how and when revenue for an element is recognized: ratably over a term, at a point in time, by percentage of completion, or on a custom schedule. Rules are assigned at the item level, so every product and service you sell carries its accounting treatment with it.
Revenue recognition plans are the schedules the rules generate. A plan says that this element’s $12,000 will be recognized as $1,000 a month from March through February. Month-end revenue processing turns the plans into journal entries that move balances out of deferred revenue and into recognized revenue, and a separate reclassification step keeps deferred revenue and unbilled receivable balances correct when billing and recognition timing differ.
One Sale, Start to Finish
Take a software company that sells a customer a 12-month subscription for $24,000, a one-time onboarding service for $6,000, and a hardware device for $2,000, on a single order with a 10 percent bundle discount.
When the sales order is approved, ARM creates a revenue arrangement with three elements. With Revenue Allocation enabled, the discounted $28,800 transaction price is allocated across the three elements based on their fair values, so the discount is spread proportionally instead of landing on whichever line the rep happened to discount. The subscription element’s rule says ratably over the term, producing a 12-line monthly plan. The onboarding element recognizes on completion. The hardware element recognizes on fulfillment.
Invoicing runs on its own schedule. If the customer is billed annually up front, deferred revenue carries the unrecognized balance and burns down monthly. If they’re billed quarterly in arrears, unbilled receivable carries recognized-but-unbilled revenue until each invoice posts. Reclassification handles the movement between those accounts. At month end, finance runs the recognition and reclassification processes, reviews the deferred revenue waterfall, and posts. No spreadsheet is involved at any step.
Setup Decisions That Shape Everything
ARM rewards planning and punishes improvisation, and a few decisions deserve real attention before the feature is switched on.
Enabling Essentials has consequences you can’t undo. Oracle’s documentation is explicit: Accounting Periods must be enabled first, the feature automatically turns on ARM in Configuration Mode, and once you leave Configuration Mode the feature can’t be disabled. Enabling it also creates system-generated accounts, including Deferred Revenue, Unbilled Receivables, and a non-posting Revenue Arrangement account. Use Configuration Mode as it’s intended: configure items, rules, and accounts completely, then leave it once, deliberately.
Item configuration is where the accounting policy actually lives. Every item needs a revenue recognition rule, a deferred revenue account, and, where relevant, a fair value setup. Decide what event starts each plan (approval, billing, fulfillment, or a custom date) and what defines the term for ratable items. Getting this right for 50 items is a workshop. Getting it right for 5,000 requires a taxonomy first.
Standalone selling prices are a policy decision, not a system setting. Revenue Allocation can hold fair value price lists and formulas, but someone has to decide what the standalone selling price of each element is and document the methodology, because that’s what auditors ask for. ARM applies the policy; it doesn’t write it.
Multi-Book Accounting matters if you report under both GAAP and IFRS, or if different subsidiaries follow different standards. ARM supports book-specific treatment, but it has to be designed in from the start.
Essentials or Revenue Allocation? A Quick Test
Three questions usually settle which edition you need. Do you sell more than one deliverable on a single contract? Do you ever discount a bundle rather than a line? Do the standalone selling prices of those deliverables differ from what the contract shows for them? Three noes means Essentials handles your world: one obligation per line, recognized on its own schedule, with no allocation math required. Any yes means the allocation step of ASC 606 applies to you, and Revenue Allocation is the module that automates it. The cost of guessing wrong runs in both directions: paying for allocation you never use, or discovering during your first audit that discounts have been landing on whichever line the rep picked.
Moving from Classic Revenue Recognition
Companies that implemented NetSuite years ago often run the older Revenue Recognition feature. Oracle’s documentation states plainly that moving from classic Revenue Recognition to ARM requires the help of NetSuite Professional Services or a qualified NetSuite partner, and there’s a reason for the rule: open revenue schedules have to be brought into the new framework without breaking the historical ledger, and the setup choices above have to be made for an existing catalog.
The transition is manageable, and worth it for any company whose contracts have grown more complex than the classic feature was designed for. It’s also a project with a real cutover, best timed at a period boundary with a clean reconciliation on both sides.
Mistakes We See
Enabling ARM during an implementation without an owner from finance. The consultant configures the mechanics, but the policy questions (what’s a performance obligation, what are our SSPs, how do we treat modifications) belong to the controller, and they need to be answered before configuration starts, not discovered during UAT.
Skipping the monthly reconciliation. Deferred revenue in the balance sheet should tie to the sum of unrecognized plan balances every month. Teams that trust the automation without proving it monthly are the ones who find a six-month-old problem during the audit.
Loading migrated contracts casually. Open contracts from a legacy system need arrangements with correct remaining balances and dates. Getting this wrong quietly misstates revenue for the life of every migrated contract.
Under-reading the reports. ARM ships with deferred revenue waterfalls, revenue-by-customer views, and forecast reports that turn the plans into a rolling revenue outlook. Companies that ignore them are running a compliance engine and leaving the forecasting value on the table.
Getting It Right
ARM is one of the areas where an experienced hand changes the outcome most. For companies going live on NetSuite, having a NetSuite implementation consultant who has configured ARM for your kind of contracts means the item taxonomy, rules, and fair value structure are designed once, correctly, before the feature is locked in. For companies already live and either moving off classic Revenue Recognition or untangling an ARM setup that never quite worked, a NetSuite consultancy with revenue recognition depth can usually diagnose the configuration in days and fix it in weeks.
Done well, ASC 606 compliance stops being a quarterly scramble and becomes a monthly process that runs in an afternoon, with a revenue forecast as a by-product. That’s the actual payoff of ARM: the compliance is the floor, and the visibility is the point.
