The Uncomfortable Truth About Your ARM Implementation

Your Advanced Revenue Management implementation looks fine on the surface. Revenue is being recognized. Journal entries are posting. Reports are generating. Auditors haven't raised red flags. Everything seems to be working.

But underneath, there are configuration issues waiting to surface. They might show up during an audit, when someone asks a question about allocation that the system can't answer correctly. They might appear during a transaction, when due diligence uncovers revenue recognition that doesn't comply with policy. They might emerge gradually, as edge cases accumulate until someone notices the numbers don't make sense.

After reviewing ARM implementations across dozens of companies, we've found that the majority have significant configuration issues. Not cosmetic problems or minor inefficiencies—real issues that affect revenue recognition accuracy.

This isn't an indictment of the people who built these systems. ARM is complex, implementations happen under time pressure, and the 80/20 rule applies: the initial configuration handles 80% of scenarios, and the remaining 20%—the edge cases, the exceptions, the unusual deals—gets deferred or handled manually. Over time, business changes. New products launch. Deal structures evolve. But the ARM configuration stays frozen in time. The gap widens until something breaks visibly.

The Most Common Misconfigurations We Find

These issues appear consistently across ARM implementations. If you haven't explicitly verified that your implementation handles these correctly, assume you have at least some of these problems.

Standalone Selling Price Problems

SSP is the foundation of ASC 606 allocation. Every dollar of transaction price gets allocated to performance obligations based on relative SSP. Get SSP wrong, and every allocation is wrong.

Outdated SSP

SSP should reflect current market pricing. But SSP in ARM often reflects pricing from implementation time—which might be years ago. Products have changed. Pricing has changed. Market conditions have changed. But the SSP driving allocations hasn't kept pace.

The symptom: allocations that produce results inconsistent with how you'd price elements if sold separately today. The risk: audit questions about SSP supportability.

Inconsistent SSP Application

Sometimes the same product has different SSP in different contexts without documented justification. Maybe one version was set during implementation and another was added later by someone who didn't check existing values. Maybe different product variations that should share SSP don't.

The symptom: identical products with different allocations on different contracts. The risk: demonstrating inconsistent policy application.

Missing SSP Documentation

ASC 606 requires that SSP determination methodology be supportable. If SSP is "observed" from standalone sales, where's the analysis showing those sales? If SSP is "estimated," what method was used and what inputs support the estimate?

Many implementations have SSP values but no documentation of how they were determined. That's an audit finding waiting to happen.

SSP That Doesn't Match Pricing Reality

Sometimes SSP was set to produce desired allocation outcomes rather than reflect actual standalone selling prices. This is backwards—SSP should be determined first, then allocation follows. If SSP was reverse-engineered from desired results, it may not survive audit scrutiny.

Fair Value Rule Errors

ARM uses fair value rules to determine how to allocate transaction prices to revenue elements. Fair value rules define which elements share allocation pools and how allocation percentages are calculated.

Percentages That Don't Add Up

Fair value rules express allocation as percentages. If you have three elements with fair value percentages of 40%, 35%, and 30%, that's 105%—which doesn't work. ARM might produce an error, or it might prorate, or it might do something unexpected.

We find fair value rules with mathematical errors more often than you'd expect. They were set up correctly initially, then individual percentages were changed without rechecking the total.

Missing Combinations

Fair value rules need to cover all combinations of elements that can appear together on contracts. If you have Elements A, B, C, and D, and fair value rules cover A+B and C+D but not A+C, contracts with elements A and C won't allocate properly.

The symptom: arrangements that fail to process or allocate incorrectly. The risk: unrecognized or misrecognized revenue.

Rules That Don't Reflect SSP

Fair value percentages should derive from relative SSP. If Element A has SSP of $100 and Element B has SSP of $200, the fair value percentages should be roughly 33% and 67%. If the configured percentages don't reflect SSP ratios, something is wrong.

Performance Obligation Mapping Gaps

Every item that can appear on a revenue-generating transaction needs to be mapped to a revenue element representing the appropriate performance obligation. Gaps in this mapping cause problems.

Unmapped Items

When an item appears on a contract that isn't mapped to a revenue element, ARM doesn't know how to handle it. Depending on configuration, this might cause arrangement creation to fail, or it might exclude the item from the arrangement entirely.

New items get added to NetSuite regularly. If the process for adding items doesn't include revenue element mapping, gaps accumulate. Eventually, a sales order includes an unmapped item and fails.

Incorrect Mapping

Sometimes items are mapped to the wrong revenue element. A professional services item mapped to a software element, for example, or a maintenance item mapped to a hardware element. The mapping affects recognition pattern, and wrong mapping means wrong recognition.

Mapping That Doesn't Match Accounting Treatment

The mapping of items to revenue elements should reflect how accounting wants to recognize revenue for those items. If accounting treats implementation services as a distinct performance obligation recognized over time, but the item mapping treats it as part of the software element recognized at point in time, there's a mismatch between policy and configuration.

Contract Modification Handling Issues

ASC 606 has specific rules for contract modifications—prospective treatment, cumulative catch-up, or treating as a new contract. The appropriate treatment depends on the nature of the modification. Most ARM implementations handle some modification scenarios well and break on others.

One-Size-Fits-All Configuration

If your ARM is configured to treat all modifications the same way (say, as prospective adjustments), but some modifications should actually be treated as cumulative catch-ups or new contracts, you're applying the wrong accounting treatment.

Missing Modification Scenarios

Some implementations only considered simple modifications during configuration. Complex scenarios—partial cancellations, scope changes that affect multiple elements, modifications that change transaction price and scope simultaneously—weren't tested and don't work correctly.

Manual Workarounds That Bypass ARM

When modifications don't process correctly in ARM, the common response is manual workaround—adjusting entries outside ARM, maintaining side calculations, or reconstructing arrangements. These workarounds might produce correct numbers, but they defeat the purpose of having ARM. They're also error-prone and difficult to audit.

Recognition Treatment Mismatches

Revenue elements have recognition treatments: point in time, over time with various methods. These treatments need to match accounting policy.

Wrong Recognition Timing

If policy says professional services should be recognized over the service period, but the revenue element is configured for point-in-time recognition, revenue will be recognized at the wrong time. This is a compliance issue.

Incorrect Period or Method

For over-time recognition, the period and method matter. Straight-line over 12 months is different from input method based on hours worked. If the configuration doesn't match how the performance obligation is actually satisfied, recognition timing will be wrong.

Inconsistent Treatment Across Similar Elements

If you have multiple revenue elements representing similar performance obligations, they should probably have consistent recognition treatments. If one software element recognizes over 12 months and another over 24 months without business justification for the difference, there's an inconsistency to explain.

Why These Problems Persist

If these issues are so common, why don't they get fixed? Several factors contribute.

Implementations Under Time Pressure

ARM implementations typically happen within broader NetSuite projects. There's a go-live date, and ARM needs to be ready. The focus is on getting something working, not getting everything perfect.

The initial configuration handles the standard cases—the majority of contracts. Edge cases get noted for "phase 2" or "future optimization." But phase 2 never happens. The edge cases get handled manually or incorrectly, and eventually everyone forgets they were supposed to be addressed.

Business Changes Without System Updates

Businesses evolve. New products launch. Pricing models change. Deal structures get more complex. But ARM configuration often doesn't keep pace.

Nobody owns ongoing ARM maintenance. When a new product launches, someone creates the item record, but maybe nobody configures the revenue element mapping. When pricing changes, someone updates price lists, but maybe nobody reviews SSP. The configuration drifts away from business reality.

Insufficient Testing

Comprehensive testing takes time. Testing every product combination, every modification scenario, every edge case—that's a lot of testing. Most implementations test the common cases, declare victory, and move on.

The uncommon cases only get discovered when they happen in production. By then, there might be months of incorrectly processed arrangements to remediate.

Lack of ARM Expertise

ARM is specialized. Many NetSuite administrators understand general NetSuite administration but not ARM specifically. Many implementation partners have broad NetSuite capability but limited ARM depth.

Complex ARM configurations require specific expertise. Without it, implementations use default settings, copy configurations that worked elsewhere, or make educated guesses. Sometimes this works. Often it doesn't.

Audit Hasn't Found It Yet

If auditors haven't raised issues, there's no urgency to investigate. Revenue is being recognized, financials are being reported, nobody's asking questions. Why look for problems?

But audit not finding an issue doesn't mean the issue doesn't exist. Auditors test samples. They check that the system does what it claims to do. They may not test every edge case or validate every SSP. Issues can persist for years until the right question gets asked.

Finding the Problems: An ARM Health Check

If you suspect your ARM configuration has issues—or even if you don't—here's how to find out.

Run Arrangement Compliance Reports

ARM tracks when arrangements fail processing or have compliance issues. Are you looking at these reports? Regularly? Non-compliant arrangements need attention. A backlog of failed arrangements indicates systematic problems.

Review the reasons for failures. Are they data quality issues (fixable at the source) or configuration issues (requiring ARM changes)? Patterns in failure reasons point to specific problems.

Validate SSP Documentation

For each SSP value in your system, can you produce documentation supporting how it was determined? If SSP was based on standalone sales, where's the analysis? If estimated, what method was used?

If you can't produce this documentation, you have an audit risk even if the SSP values happen to be correct.

Review Fair Value Rules Mathematically

Export your fair value rules and check the math. Do percentages for each combination add to 100%? Do the percentages reflect relative SSP? Are all expected combinations covered?

This is mechanical work but important. Mathematical errors in fair value rules produce systematically wrong allocations.

Audit Item-to-Element Mapping

Pull a list of all items that can appear on revenue-generating transactions. Check that each one is mapped to an appropriate revenue element. Look for gaps. Look for mappings that don't make sense.

For new items added recently, was revenue element mapping part of the setup process? If not, those items might be unmapped.

Test Modification Scenarios

Don't wait for real modifications to discover problems. Create test modifications in sandbox:

• Quantity increase on existing contract

• Quantity decrease (partial cancellation)

• Price change on remaining deliverables

• Term extension

• Scope addition with new elements

• Complete cancellation

Verify each scenario processes correctly and produces expected accounting results.

Compare Recognition to Policy

For each revenue element, document the configured recognition treatment. Compare to accounting policy documentation. Do they match? If policy says "over the service term" and configuration says "point in time," there's a gap.

Reconcile ARM to GL

ARM schedules revenue recognition. The GL records it. These should reconcile perfectly. If they don't—if there are timing differences, unrecognized amounts, or unexplained variances—something is wrong somewhere.

Regular reconciliation between ARM and GL catches issues early.

Fixing the Problems

Once you've identified issues, how do you fix them without disrupting ongoing operations?

Prioritize by Risk

Not all issues are equally serious. Prioritize based on:

• Financial impact: How much revenue is affected?

• Compliance risk: How likely is this to be an audit issue?

• Frequency: How often does this scenario occur?

• Trending: Is the issue getting worse over time?

Fix high-impact, high-frequency issues first. Low-impact edge cases can wait.

Fix Configuration in Sandbox First

Never fix ARM configuration directly in production. Make changes in sandbox, test thoroughly, then deploy to production. ARM configuration changes can affect historical arrangements, not just new ones. Unintended consequences are common.

Address Data Quality Separately

If issues trace to data quality (missing fields, incorrect SSP on items, inconsistent data entry), address data quality as a separate workstream. Clean data is a prerequisite for ARM working correctly.

Document All Changes

Every configuration change should be documented: what changed, why, what was it before, what is it now, who approved. This documentation supports audit and helps future troubleshooting.

Test Extensively Before Deploying

After fixing configuration, test every scenario you can think of. Test the specific issues you identified. Test related scenarios that might be affected. Test scenarios that were working to ensure they still work.

ARM changes can have unexpected effects. Testing catches surprises before they hit production.

Plan for Historical Remediation

If past arrangements were processed incorrectly, you may need to remediate historical data. This might mean adjusting revenue schedules, posting correcting entries, or reconstructing arrangements.

Historical remediation is its own project. Don't underestimate the effort required, especially if issues span many periods.

Building Ongoing ARM Governance

Fixing current issues is necessary but not sufficient. Without ongoing governance, new issues will accumulate and you'll be back here in a year.

Establish ARM Ownership

Someone—a person, not a department—needs to own ARM configuration. They're responsible for maintaining configuration, reviewing new product setups, validating SSP, monitoring arrangement health.

Without clear ownership, ARM becomes everyone's and no one's responsibility.

Integrate ARM Into Product Launch Processes

When new products launch, ARM configuration should be part of the launch checklist. Revenue element mapping, SSP determination, recognition treatment configuration—all done before the first sale, not discovered missing after.

Schedule Regular SSP Review

SSP should be reviewed at least annually, more frequently if pricing changes often. Build SSP review into the annual close or another regular process. Document reviews even if SSP doesn't change.

Monitor Arrangement Health Continuously

Don't wait for month-end to check arrangement processing. Daily or weekly monitoring catches issues early when they're easier to address. Build arrangement health metrics into operational dashboards.

Conduct Periodic ARM Audits

Beyond ongoing monitoring, conduct deeper periodic reviews. Annually, at minimum, review the complete configuration, test modification scenarios, validate SSP documentation, and reconcile ARM to GL for the full year.

The Role of Custom Extensions

Sometimes native ARM configuration can't handle your requirements. Custom development can fill gaps.

Custom Allocation Logic

If your allocation requirements exceed what fair value rules can express, custom scripts can implement more complex allocation methodologies while integrating with ARM's arrangement structure.

Automated Exception Handling

Failed arrangements need attention. Custom workflows can route exceptions to the right people, track resolution, and escalate if issues aren't addressed timely.

Enhanced Reporting

ARM's native reporting may not meet all needs. Custom reports can provide visibility into arrangement status, compliance metrics, and operational KPIs beyond what native reports offer.

Integration Automation

If contract data comes from external systems (CRM, CPQ, contract management), custom integrations can automate data flow and validation, reducing manual entry and associated errors.

Bottom Line

ARM is powerful but unforgiving. It does exactly what you tell it to do—even when what you told it is wrong. Configuration errors don't announce themselves; they quietly produce incorrect results until someone notices.

The issues we've described are common because ARM is complex, implementations happen under pressure, and ongoing maintenance is often neglected. But common doesn't mean acceptable. Each issue represents compliance risk, audit risk, or simply wrong revenue recognition.

Regular configuration audits aren't overhead; they're insurance against revenue restatements. The cost of proactive review is trivial compared to the cost of fixing problems after auditors find them.

And when native configuration falls short, thoughtful customization closes the gap. ARM is a platform. The companies that get the most value from it are those that invest in building it out fully—not just the initial configuration, but the complete, ongoing solution that their business requires.