The Gap Between Theory and Reality
ASC 606 looks straightforward in the accounting literature. Five steps, clearly defined. Identify the contract. Identify performance obligations. Determine transaction price. Allocate to performance obligations. Recognize revenue when obligations are satisfied. Simple, right?
Then you try to implement it in NetSuite's Advanced Revenue Management module and discover that the gap between GAAP theory and ERP configuration is measured in months of effort, thousands of dollars in consulting fees, and more than a few sleepless nights before go-live.
The standard is elegant in its conceptual framework. The reality of encoding that framework into software—software that must handle your specific contracts, your specific products, your specific edge cases—is considerably messier.
After supporting dozens of ARM implementations across industries from SaaS to manufacturing to professional services, here's what we wish someone had told us—and what we now tell every client before they start.
The Five-Step Model in Theory vs. Practice
Let's walk through each step of ASC 606 and examine where implementation complexity hides.
Step 1: Identify the Contract
In theory: A contract exists when it's approved, has commercial substance, and defines rights and payment terms.
In practice: What constitutes a "contract" in your business? Is it the signed MSA? The individual work order? The combination? What about verbal agreements, handshake deals, or implied renewals? How do you handle contracts that start before paperwork is complete?
ARM needs clear rules for what creates a contract in NetSuite. This means defining which transaction types trigger revenue arrangements, how contract inception dates are determined, and how contract boundaries are established when multiple documents are involved.
The accounting guidance gives principles; your implementation needs policies. Those policies need to be specific enough to encode in software and defensible enough to survive audit scrutiny.
Step 2: Identify Performance Obligations
In theory: Identify distinct promises to transfer goods or services.
In practice: Which elements of your offerings are distinct? If you sell software with implementation services, is that one obligation or two? If you bundle hardware with a maintenance contract, how do you determine distinctness? What about options, upgrades, and add-ons?
The distinctness determination requires judgment, and that judgment must be consistently applied. ARM doesn't make these decisions for you—it enforces whatever decisions you configure. Get the mapping of items to performance obligations wrong, and your entire revenue recognition is wrong.
Companies with complex product catalogs often underestimate this step. You might have hundreds of SKUs, but how many distinct performance obligations do they represent? Creating and maintaining that mapping is ongoing work, not a one-time implementation task.
Step 3: Determine the Transaction Price
In theory: The amount of consideration you expect to receive, adjusted for variable components.
In practice: Variable consideration—discounts, rebates, bonuses, penalties, rights of return, price concessions—is where ASC 606 gets complicated. You must estimate variable amounts at contract inception and update estimates over time.
ARM can handle variable consideration, but the complexity depends on your pricing models. Simple fixed-price contracts are straightforward. Usage-based pricing, performance bonuses, and tiered discounts require more sophisticated configuration and potentially custom development.
Constraining variable consideration—ensuring you don't recognize revenue that might need to be reversed—requires ongoing analysis of historical patterns and prospective estimates. ARM tracks the numbers; you provide the judgment.
Step 4: Allocate to Performance Obligations
In theory: Allocate transaction price based on standalone selling prices.
In practice: Determining standalone selling prices is one of the most judgment-intensive aspects of ASC 606. If you sell something both bundled and standalone, you have observable SSP. If you only sell it bundled, you need to estimate SSP using acceptable methods: adjusted market assessment, expected cost plus margin, or residual approach.
These judgments are material. The SSP determines how much revenue is allocated to each element, which affects timing of recognition. If you allocate more to the upfront element, you recognize revenue sooner. The accounting policy implications are significant.
ARM requires you to configure SSP for every item that can appear in a revenue arrangement. For companies with large product catalogs, this is substantial initial work and ongoing maintenance as products and prices change.
Step 5: Recognize When Obligations Are Satisfied
In theory: Point in time or over time, depending on the nature of the obligation.
In practice: Point-in-time recognition is relatively straightforward—revenue recognized when control transfers. Over-time recognition requires determining the method: output method, input method, or straight-line as a practical expedient.
For over-time recognition, ARM can apply different methods and periods. But you must determine which method applies to each performance obligation and configure accordingly. Inconsistent application of recognition methods is an audit finding waiting to happen.
What Controllers Learn the Hard Way
Beyond the conceptual complexity, ARM implementations reveal practical challenges that aren't obvious until you're in the middle of them.
Data Quality Is Everything
ARM can only recognize revenue correctly if it has clean, complete contract data. The module is sophisticated, but it operates on whatever information flows into it. Garbage in, garbage out has never been more true.
Common data quality issues that break ARM:
Missing performance obligations on sales transactions
Incorrect standalone selling prices on items
Contract modifications without proper documentation
Inconsistent use of item records across contracts
Timing mismatches between billing and revenue arrangements
Data quality issues don't just cause wrong numbers—they cause arrangement processing failures. Contracts that can't be recognized create backlogs that compound over time. A few bad contracts in month one become an overwhelming remediation project by month six.
Your Contracts Are Messier Than You Think
Most companies believe their contracts are standardized. "We have three pricing models and two contract templates. It should be straightforward."
Then you start mapping actual contracts to ASC 606's five-step model and discover:
Legacy contracts with terms that don't match current templates
Side letters and verbal agreements that modify standard terms
One-off deals for strategic customers with unique pricing
Contracts that span multiple years with escalating terms
Amendments and modifications that change original arrangements
Renewal terms that differ from original contract terms
Each exception requires either specific handling in ARM configuration or manual treatment outside the system. The number of exceptions typically exceeds initial estimates by a factor of three or more.
ARM Configuration Reflects Judgment Calls
ASC 606 requires significant management judgment. ARM doesn't reduce that judgment—it enforces whatever judgments you configure.
Critical judgments that flow into ARM:
What constitutes a distinct performance obligation
How to determine standalone selling prices
When to apply the constraint on variable consideration
Which recognition method applies to which obligations
How to treat contract modifications
These decisions have real financial impact. Two companies with identical contracts might recognize revenue differently based on their ASC 606 judgments. ARM makes those judgments auditable and consistent—but the judgments themselves are yours to make and defend.
Testing Takes Longer Than Building
The configuration might take weeks. Testing every scenario—new contracts, modifications, renewals, cancellations, variable consideration adjustments—takes months.
Effective testing requires:
Representative contracts from every product and pricing combination
Modification scenarios for each type of contract change
Cancellation handling across different contract stages
Renewal processing with various term changes
Variable consideration estimation updates
Period-end processing and reporting
Historical migration validation
Each scenario needs expected results documented before testing. When results don't match expectations, you need to determine whether the configuration is wrong or the expectation was wrong. This takes time.
Cutting testing short is how companies end up restating revenue. The cost of additional testing time is trivial compared to the cost of getting revenue recognition wrong.
Historical Migration Is Its Own Project
If you're implementing ARM on a live system with existing contracts, you need a migration strategy. Options include:
Prospective Only
Apply ARM only to contracts after go-live. Existing contracts continue on legacy recognition. This is simplest but creates parallel tracking requirements—some contracts in ARM, some outside.
Full Historical Migration
Migrate historical contracts into ARM and retrospectively adjust. This provides clean, consistent treatment going forward but requires significant effort to migrate historical data and validate results.
Hybrid Approach
Migrate some historical contracts (e.g., those with remaining performance obligations) while leaving completed contracts alone. Balances completeness against effort.
Each approach has trade-offs. The choice depends on your contract volume, remaining obligations on existing contracts, and capacity for migration work.
Common Implementation Pitfalls
These issues appear consistently across ARM implementations.
Starting with Configuration Before Policy
Jumping into NetSuite configuration before documenting ASC 606 policies creates rework. You configure based on assumptions, discover the assumptions don't match accounting's requirements, and reconfigure.
The correct sequence:
Document accounting policies for each ASC 606 judgment area
Get policies reviewed by external auditors
Design ARM configuration to implement policies
Build and test configuration
Validate results against policy documentation
Policy documentation should exist before anyone touches NetSuite. This sequence adds time upfront but saves much more time downstream.
Underestimating SSP Complexity
Standalone selling price determination is often treated as a quick exercise. List your products, assign prices, done.
In practice:
Observable SSP requires analysis of standalone sales history
Estimated SSP requires defensible methodology and documentation
SSP may vary by customer segment, geography, or channel
SSP needs periodic review and update as markets change
New products need SSP determination before they can be sold
Companies that shortcut SSP work find themselves revisiting it repeatedly—and explaining their methodology to auditors who have questions.
Ignoring Contract Modification Complexity
ASC 606 treatment of contract modifications depends on whether the modification adds distinct goods/services at standalone selling price. Different answers lead to different accounting treatments.
ARM needs to handle all modification scenarios your business encounters. Common issues:
Partial cancellations that change allocation
Price changes on remaining performance
Scope additions that may or may not be distinct
Extension renewals that change original terms
Bundling changes that affect distinctness
If your configuration handles only simple modifications, complex ones will fail or process incorrectly. Design for the full range of modifications your business might see.
Insufficient Integration Between Billing and Revenue
ARM operates on revenue arrangements that should integrate seamlessly with billing. When billing and revenue recognition diverge, reconciliation becomes painful.
Common integration issues:
Invoices that don't tie to revenue arrangements
Billing adjustments not reflected in revenue schedules
Timing differences between billing milestones and revenue recognition
SuiteBilling subscriptions that don't flow cleanly to ARM
The integration between billing and ARM deserves as much attention as ARM configuration itself. Plan for it.
Getting It Right: A Practical Implementation Approach
Here's how to approach ARM implementation with eyes open to the challenges.
Phase 1: Accounting Policy Development
Before touching NetSuite:
Document ASC 606 policies for your business
Define performance obligations for all product/service types
Document SSP determination methodology
Define contract modification treatment
Specify recognition methods and periods
Get policies reviewed by auditors
This phase involves accounting leadership, not IT or NetSuite administrators. The output is accounting policy documentation that drives everything else.
Phase 2: Data Preparation
Clean and prepare data for ARM:
Review and correct item master data
Validate SSP on item records
Clean up revenue element configurations
Identify historical contracts requiring migration
Document contract data quality issues
Data problems discovered during configuration are expensive to fix. Find them early.
Phase 3: Configuration Design
Design ARM configuration to implement policies:
Revenue recognition rules matching policy documentation
Fair value rules implementing allocation methodology
Recognition treatment settings for each element type
Contract modification handling logic
Integration points with billing and other modules
Document design decisions and map them to accounting policies. This documentation serves implementation and audit purposes.
Phase 4: Build and Unit Test
Build configuration and test individual components:
Configure revenue elements
Set up fair value rules
Configure recognition treatments
Build arrangement creation rules
Test each component individually
Unit testing validates that individual pieces work before testing them together.
Phase 5: Integration Testing
Test end-to-end scenarios:
Create test contracts representing all product combinations
Process through arrangement creation
Verify allocation calculations
Test recognition over appropriate periods
Validate integration with billing
Test modification scenarios
Test cancellation handling
Integration testing requires documented test cases with expected results. Manual verification that results match expectations.
Phase 6: Historical Migration
If migrating historical contracts:
Extract historical contract data
Prepare migration files
Load to sandbox environment
Validate migrated arrangements
Reconcile to legacy revenue schedules
Document and resolve discrepancies
Historical migration is its own project. Don't underestimate it.
Phase 7: Parallel Processing
Run ARM in parallel with legacy recognition:
Process new contracts through both methods
Compare results
Investigate discrepancies
Refine configuration as needed
Build confidence in ARM accuracy
Parallel processing catches issues before they affect reported financials.
Phase 8: Go-Live and Stabilization
Transition to ARM as system of record:
Cut over to ARM processing
Monitor arrangement processing closely
Address exceptions quickly
Validate first month-end close
Stabilize and document steady-state processes
The Role of Customization
ARM handles standard scenarios well. Unique business requirements often need custom extensions.
Custom Processing for Edge Cases
If you have contract scenarios that ARM can't handle natively—complex bundling rules, unusual modification treatments, non-standard variable consideration—custom SuiteScript can fill gaps.
Custom code should integrate cleanly with ARM, not bypass it. The goal is extending ARM's capability, not creating parallel revenue recognition systems.
Integration Automation
Integration between source systems (CRM, CPQ, contract management) and ARM often requires custom development. Automated contract data flow reduces manual entry and associated errors.
Reporting Extensions
ARM's native reporting may not meet all needs. Custom reports and dashboards can provide visibility into revenue schedules, arrangement status, and compliance metrics beyond what native reports offer.
Exception Handling Automation
Arrangements that fail processing need attention. Custom automation can route exceptions, notify responsible parties, and track resolution—ensuring failed arrangements don't accumulate.
Ongoing Compliance: ARM Is Not Set-and-Forget
Implementation is just the beginning. ARM requires ongoing attention.
SSP Maintenance
Standalone selling prices need periodic review. Market conditions change. Product positioning shifts. What was valid SSP last year may not be valid this year. Build SSP review into regular processes.
New Product Setup
Every new product or service needs proper ARM setup before sale. Revenue element assignment, SSP determination, and recognition treatment must be configured. Build this into product launch processes.
Policy Updates
Contract structures evolve. New deal types emerge. Policies need updates, and ARM configuration needs to follow. Don't let configuration drift from documented policy.
Processing Monitoring
Monitor arrangement processing regularly. Failures need quick attention. Backlogs are easier to address when small. Build arrangement health monitoring into regular operations.
Audit Support
Auditors will ask questions about ASC 606 implementation. Maintain documentation that supports your policies and demonstrates consistent application. ARM provides data; you provide the narrative.
The Real Question
ARM is a powerful module. With proper implementation, it automates revenue recognition at scale, ensures consistent policy application, and provides audit-ready documentation.
But it's only as good as the accounting policies it enforces and the data it processes. The question isn't whether ARM can handle ASC 606—it's whether your organization is ready for the discipline ASC 606 requires.
That readiness means clear policies, clean data, comprehensive testing, and ongoing maintenance. Companies that invest in this foundation get reliable revenue recognition. Companies that shortcut it get audit findings and restatements.
The choice is yours. But make it with eyes open to what's actually involved.
