NetSuite ARM Contract Modification: Prospective Merge Guide

Executive Summary

A signed contract amendment forces two separate decisions, and NetSuite Advanced Revenue Management (ARM) only helps with the second one. The first is an accounting conclusion. Under ASC 606 (the US revenue standard, codified by the Financial Accounting Standards Board) and IFRS 15 (the international equivalent), a modification is a change in scope or price approved by the parties ^[1]. It then lands in one of three places: a separate contract when distinct goods or services are added at a price reflecting standalone selling price (SSP) ^[2]; a prospective "termination and new contract" when the remaining goods or services are distinct ^[3]; or a cumulative catch-up when they are not ^[2].

Only then does the system question arise. Oracle documents two merge paths. A combined revenue arrangement moves elements into a new arrangement while originals remain editable, whereas a prospective merge locks the originals and generates new elements and plans carrying residual values, computed from a residual ratio of amount recognized to original base-currency revenue ^[4]. An independent review of the module describes the same behavior: originals are locked and residual values carry forward from the first open period ^[5].

The gates matter at close. As of October 2026, the effective date is the first day of the first open period that is not an adjustment period ^[6], and a merge cannot be created if recognition or reclassification journals were already posted after that date. Revert is available only until recognized revenue, reclassified deferred revenue, or contract acquisition costs exist on the merged arrangement.

The practical rule is sequencing: sign-off first, then merge type, then preview, then evidence. This report supplies a decision tree, a matrix mapping each accounting conclusion to an ARM action, a reconciliation equation, a test plan, and a fictional change order in which $105,000 recognized to date and $30,000 of unrecognized original value combine with $78,000 of new consideration into $108,000 of remaining consideration. Prospective merge is not the answer to every amendment. Software that executes a merge does not make the underlying conclusion compliant, and each contract needs review by a qualified accountant ^[1].

Introduction and Background

Controllers and NetSuite owners tend to meet contract modifications in an awkward week: an upsell, a partial cancellation, or a discounted renewal is signed near month-end, and someone must decide whether the revenue arrangement should be merged, combined, left alone, or rebuilt. The question is rarely "what is a contract modification". It is "which action, and what does it lock". This report is written for the SaaS controller, the revenue accounting manager, the ARM owner, and the systems architect who share that decision.

The scope is deliberately narrow. It is not a general ASC 606 five-step overview and not a comparison of ARM product tiers. It starts from the signed amendment, works through the performance obligation judgment, and then maps each conclusion to ARM mechanics documented by Oracle. Where Oracle's pages are silent, the report says so and recommends a sandbox test rather than guessing.

Four framing points apply throughout:

• ASC 606 and IFRS 15 share the framework. The TRG staff paper pairs each US paragraph with its IFRS counterpart, for example ASC 606-10-25-12 with IFRS 15 paragraph 20 ^[1].
• Accounting leads, the system follows. The standards call for judgment about distinct goods or services and SSP. That judgment sits with the preparer and the reviewer. KPMG's handbook introduction notes that questions keep arising as companies enter new or modified revenue arrangements ^[7].
• Terminology differs by source. Oracle sometimes calls a combined arrangement a "retrospective merge", and its prospective merge page contrasts the two. This report uses "combined arrangement" and "prospective merge".
• Facts are dated. Every ARM behavior described here reflects Oracle help pages read on 2026-10-31. NetSuite ships releases on a fixed cadence, so confirm each gate in your own account and release.

Licensing is a threshold fact. An independent review describes ARM as two features, Advanced Revenue Management (Essentials) plus a Revenue Allocation add-on for fair value pricing ^[5], and states that Oracle publishes no price for the module ^[5]. The distinction matters here because some prospective merge fields, including the residual fair value option, appear only with Revenue Allocation.

Houseblend, a Montréal NetSuite consultancy, implements and administers ARM for scale-ups and mid-market companies. This report is general information, not accounting or legal advice, and it has not been reviewed by a licensed accountant. Conclusions on specific contracts require a qualified professional.

From Signed Amendment to Accounting Conclusion

Step 1: Intake and approval

A modification exists once the parties approve a change that creates or alters enforceable rights and obligations. Deloitte's accounting spotlight, as hosted by IAS Plus, puts it plainly: whenever those rights and obligations change, a modification is present and the framework applies ^[8]. The preparer must then assess the goods and services and their selling prices ^[8]. The Transition Resource Group (TRG) staff paper, which is staff material rather than the standard itself, adds that approval can be written, oral, or implied by customary business practices ^[1], and that a modification can exist even while the parties dispute scope or price ^[1]. ICAEW's question flow starts the same way, with approval, and says that without it the previous accounting continues ^[2].

For the ARM owner, the intake package should therefore contain the signed amendment, side letters, approval evidence, and the order or orders that will become NetSuite sources. If scope is approved but price is not, the staff paper says the entity estimates the change to the transaction price ^[1]. An unpriced change should not trigger a merge until the accounting team has documented that estimate. Baker Tilly stresses that proper accounting of modifications requires additional judgment and documentation ^[9], and Cohen & Company points to estimating the change using historical, current, and forecast information ^[10].

Step 2: The performance obligation decision tree

The standards set out an ordered test. The sequence below paraphrases ASC 606-10-25-10 through 25-13 and IFRS 15 paragraphs 18 to 21, with the TRG staff paper, PwC, and ICAEW as the cited text:

1. Is the change approved? If not, continue the previous accounting ^[2].
2. Does scope increase through distinct goods or services priced at SSP? Both conditions must be present for separate-contract treatment ^[3]. The first is a scope increase from added distinct goods or services ^[1]. The second is a price increase that reflects the entity's standalone selling prices of the additions, adjusted for the circumstances of the contract ^[1]. If both hold, the original contract is unaffected ^[2].
3. If not a separate contract, are the remaining goods or services distinct? If yes, the modification is treated as a termination and a new contract, and revenue recognized to date is not adjusted ^[1]. The remaining consideration is allocated to the remaining performance obligations ^[1]. The assessment covers all remaining goods and services at the time of the modification, not only those the amendment adds ^[11]. ICAEW describes the new contract's consideration as the unrecognized amount under the old contract, adjusted for the change the modification brings ^[2].
4. If the remaining goods or services are not distinct, is there one partially satisfied obligation? Then the change is treated as part of the original contract and revenue is adjusted on a cumulative catch-up basis ^[1]. ICAEW describes the non-distinct items as part of a single performance obligation that is partially satisfied ^[2].
5. Is it a mix? A change can combine both, leaving completed distinct obligations untouched ^[1].

Three cautions belong in every technical-accounting memo. First, the reasoning of the FASB and the International Accounting Standards Board (the Boards) is that some modifications should be prospective and others cumulative catch-up so as to faithfully depict the modified contract ^[3]. Prospective treatment applies even when the added goods are not priced at SSP ^[3]. Second, ICAEW stresses that deciding whether remaining goods and services are distinct is not the same as identifying separately identifiable performance obligations ^[2]. Third, where only some remaining goods or services are distinct, IFRS 15 is not prescriptive about the mechanics ^[2].

Step 3: SaaS-specific judgment

For SaaS, series guidance usually points toward prospective treatment. PwC observes that a promise of SaaS access is typically a series of distinct goods or services ^[12], so a SaaS modification is generally either a separate contract or a termination and new contract under ASC 606-10-25-13(a) ^[12], and ICAEW's telecom illustration reaches the same place for a mid-term change ^[2]. "Usually" is not "always". PwC notes that the additional consideration may fail to reflect SSP when quantities are variable ^[12], and that preparers should weigh all facts and circumstances ^[12].

Some upsell structures sit outside the standard's direct text. PwC's discussion of converting an on-premises license to SaaS states that the revenue standard does not directly address that scenario ^[12], and describes two views that differ on whether a credit is a discount or a refund. Under the first view there is no further accounting for the license cancellation ^[12]. A rip-and-replace amendment is the kind of change that should reach technical accounting before anyone selects arrangements in NetSuite.

Public filers use compact versions of the same language. One filer states that a modification meeting both criteria is accounted for as a separate contract ^[13], and one that does not is accounted for prospectively or on a cumulative catch-up basis ^[13]. A subscription company's annual report says modifications that extend a term or add subscription products are generally treated as a termination of the old contract and creation of a new one ^[14]. These are policy descriptions, not a template for any other company.

Step 4: Mapping the conclusion to an ARM action

Table 1 below converts each accounting conclusion into the ARM action Oracle documents and flags what ARM does not decide. Where the ARM path and Watch-outs columns describe a documentation gap, it is this report's analysis, not an Oracle statement.

Table 1 shows why "use prospective merge" is not a universal answer. Only the second row, and in practice one flavor of the fourth, leads there. The matrix also exposes the weakest link in many implementations: the catch-up path has the thinnest vendor documentation, so it deserves the most sandbox testing. A related blog from RevenueHub describes the prospective method as treating the original contract as terminated and accounting for it with the modification as a newly created contract ^[11], which is the accounting a prospective merge implements and no more.

Combined Arrangements Versus Prospective Merges in ARM

What each path does

A combined arrangement represents a single obligation. Elements from multiple sources are merged into one arrangement, the originals are preserved without the merged elements, and they keep the history and audit trail. If the plan update frequency is set to Manual, plans must be updated by hand after the merge.

A prospective merge instead uses residual values. NetSuite generates new elements and plans for the unrecognized remainder, while recognized periods stay on the locked originals ^[4]. The new plans start on the effective date, and amounts planned before that date but not yet recognized roll into them. The locked originals get an effective end date one day before the merge effective date.

Table 2 condenses the documented differences.

Table 2 needs two readings. The revert row reflects what the pages reviewed document, not a claim that no other mechanism exists; confirm with Oracle Support for your release. The start-date row reflects a recent behavior: a Crowe summary of the 2025.1 release describes aligned start dates as a change to retrospective merging ^[16].

The residual ratio in practice

The calculation is simple, and the simplicity is the audit point. Residual amounts equal one minus the residual ratio, times the original amount, and the ratio uses base-currency amounts that exclude foreign currency revaluation adjustments ^[4]. In the new arrangement, the discounted sales amount becomes the original amount minus the amount recognized before the merge. Quantity, sales amount, and calculated fair value are scaled by the ratio in the same way.

Two consequences follow. First, fully recognized elements still appear in the new arrangement with a zero residual, because they are required to support reclassification. Second, a prospective merge can be repeated: later merges can include a prospective merge arrangement, but elements cannot be added or removed by editing it. A second amendment therefore starts a new decision, not an edit.

Effective date versus modification date

The effective date is not a field the user enters. The accounting modification date is when the parties approved the change, and approval can be written, oral, or implied ^[1]. If an amendment is signed on the 12th of an open month, ARM's start-of-month convention differs from the contractual date. The difference may be immaterial, but that is a documented judgment for the technical accounting reviewer, not an assumption to make silently.

Gates, Preview, and Approval Controls

Hard gates before the merge can be created

Oracle lists conditions that block a prospective merge. Treat them as a pre-flight checklist for the change order owner:

• Open period. If prior changes have not posted, reopen the prior period and post them first, because a merge cannot be created once recognition or reclassification journals exist after the effective date ^[6].
• Plans up to date. No selected element may require a plan update ^[6]. Oracle notes that this condition does not apply where elements have no existing plans.
• Operating limits. Automatic plan updates run every 3 hours ^[17], and Oracle's SuiteScript merge task documentation states that a merge cannot include more than 10,000 revenue elements at one time; the help page for the merge UI states no numeric cap ^[18].

Unsupported plan types and arrangements

Oracle lists plan types a prospective merge does not support: project revenue plans, subscription revenue plans when the Create Revenue Elements for Subscription Revisions preference is clear, and plans from certain custom revenue events, and it adds that field mapping is unsupported in prospective merge arrangements ^[4]. That preference is permanent once set ^[19], so it is an architecture decision, not a toggle to flip during close. The field-mapping limit matters if downstream reporting depends on mapped custom fields.

For subscription businesses, the term "change order" is overloaded. In SuiteBilling, a change order is a billing record, and it is not itself the accounting conclusion. Keep the billing change order and the ARM merge as separate objects in the evidence pack.

Preview, approval, and audit trail

The Preview Revenue Arrangement page is read-only and shows transaction total, carve-out, and revenue amounts before and after, element by element. Oracle says a user can click Merge without previewing, but that it is not best practice ^[6]. Make the preview a required control: export it, and have the reviewer sign it before the merge executes.

Approval routing adds a second control. When it is used, recognition and reclassification journals cannot be generated until the arrangement is approved ^[20]. ARM adds revenue manager and revenue accountant roles, and both default to full permission for revenue recognition processing ^[21], which is the cue to restrict who can run merges.

For audit trail, revenue plans retain previous versions with the date and user name. Auditors who rely on company-produced information must evaluate whether it is sufficient and appropriate ^[22], which includes testing accuracy and completeness or the controls over them ^[22]. PCAOB AS 1105 also says such information is more reliable when the company's controls over it are effective ^[22]. Evidence from a knowledgeable independent source is also more reliable than evidence from internal sources alone ^[22], so pair system exports with the signed amendment and approvals. The preview, system notes, and plan version history are evidence, but only if the controls around them operate.

Reclassification, Contract Costs, Currency, and Allocation

Reclassification and the locked originals

Reclassification runs for both the locked original arrangement and the new merged arrangement ^[4]. For the original, carve-in and carve-out postings are unwound and billed and recognized totals must line up. Deferred revenue balances carried to the merged arrangement are reallocated on the new carve-in and carve-out ratio. Because reclassification journals posted after the effective date block the merge, the sequence at close is: finish prior-period work, merge, then run recognition followed by reclassification. Oracle states that these processes should run in that order ^[23].

One restriction affects rework: running reclassification in a reopened period requires reverting any prospective merges first. Reopening a period after a merge is therefore a multi-step event, not a toggle.

Contract acquisition costs

With Advanced Cost Amortization enabled, a merge reverses contract cost deferral journals, links them to the old arrangements, and creates a new deferral on the new arrangement ^[24]. Allocated acquisition cost is not reallocated automatically; the Reallocate Cost button does that. Because a merged arrangement holding contract acquisition costs cannot be reverted, the commission or cost owner should sign off before the merge, not after. Whether capitalized costs need reassessment because of the amendment is an accounting question for the reviewer; this report states no rule.

Multi-currency and SSP effects

For foreign-currency arrangements, the exchange rate on each element stays the same after the merge. For combined arrangements, merging elements at different exchange rates recalculates plan exchange rates so that all resulting plans share one. Run at least one multi-currency UAT (user acceptance testing) scenario with a rate change between the order date and the amendment date.

On SSP, the Recalculate Residual Fair Value box appears only when Revenue Allocation is enabled, and fair values to be recalculated should include the quantity field. If the box is cleared, fair value stays at the original calculated amount times one minus the residual ratio. In both cases the accountant's SSP analysis defines the correct allocation; the fair value price list should be made to reproduce it. PwC's blend-and-extend example shows why. A SaaS vendor with a three-year $900,000-per-year contract modifies it at the end of year two ^[12], and whether the added year's price reflects current SSP decides whether the change is a separate contract ^[12].

Reconciliation, UAT, and the Close Evidence Pack

The reconciliation equation

The core control total for a prospective-merge conclusion is:

• Original unrecognized balance (original amount minus recognized to date, per element)
• plus new consideration (amendment value, net of any item the accountant excludes)
• equals new remaining consideration (the sum of residual-value elements after allocation)
• adjusted for contract-specific accounting (for example, variable consideration, credits, or cost treatment documented in the memo).

This mirrors the IFRS 15 description of the new contract's consideration as unrecognized old consideration adjusted for the modification ^[2]. If the preview total, the sum of new plan lines, and the memo schedule do not agree, stop. A second check belongs in the pack: lifetime revenue (recognized to date plus new remaining consideration) should equal original contract value plus new consideration, unless the memo explains a difference.

UAT cases

Test in a sandbox refreshed from production close to the cutoff, with periods configured as in production. Minimum cases:

• Upsell with discount. Added modules at a discount to SSP; confirm the conclusion (separate contract versus prospective) and, for the merge case, that allocation matches the memo.
• Partial cancellation. Reduced scope with a credit; confirm the sign of residual amounts and the reclassification effect on billed versus recognized totals.
• Return or credit. Returns are merged with the original sale so that negative elements link to positive ones ^[5]; confirm that link and that the return carries the same exchange rate as the linked sales order.
• Cumulative catch-up. A combined arrangement with the same start dates; confirm the current-period adjustment equals the accountant's calculation, which compares cumulative revenue under the new terms with revenue recognized to date ^[2].
• Gate failures. A journal already posted after the effective date, a stale plan, an inactive source item, and mismatched contract acquisition accounts; each should block the merge as expected.
• Revert. One merge with no recognized revenue (revert succeeds) and one with recognized revenue (revert unavailable).
• Multi-currency. A rate move between orders; confirm element exchange rates and reclassification.

The close evidence pack

An evidence register for each amendment should include:

• Signed amendment and approval record, with date and approver.
• Technical-accounting memo, including distinct and SSP analysis and the conclusion.
• Pre-merge snapshot, including plans and a recognized-to-date schedule by element.
• Preview export, reviewed and signed.
• Post-merge arrangement view, showing locked originals, effective dates, and new plans.
• Reconciliation workbook with the equation above.
• Journal listing for recognition and reclassification in the first period after the merge.
• System notes and plan version exports from the audit-trail locations described earlier.

Rollback and escalation

Rollback is a short window. Prospective merge arrangements include a Revert Change Order button, and it works only until the new arrangement has recognized revenue, reclassified deferred revenue, or contract acquisition costs. After that point Oracle's page documents no revert path, so escalate to the revenue manager, the technical accounting lead, and, where needed, Oracle Support. Corrections after that point follow company policy and are decided by the accounting team.

Data Analysis and Evidence

The evidence supporting this report is mostly rule text rather than market statistics, so the useful quantitative check is arithmetic: do published examples reproduce under the stated formulas?

Oracle's $1,200 example. An element of $1,200 recognized evenly over six months, merged prospectively with a September 1 effective date, leaves $400 (July and August at $200) on the locked element and $800 on the new element ^[4]. The residual ratio is $400 divided by $1,200, or one third, and the residual is (1 minus one third) times $1,200, or $800. Oracle's new actual plan shows four monthly lines of $200 from September to December. Oracle's forecast plan spreads the same $800 as $133.33 for five months (September to January) and $133.34 for the sixth (February); the six printed lines total $799.99, a one-cent rounding difference against $800. The actual plan (four lines of $200) and the residual calculation ($1,200 x (1 - 1/3) = $800) do reproduce.

PwC's blend-and-extend example. The contract is modified to extend one year and set a blended rate of $850,000 per year for the remaining two years ^[12]. The implied price of the extension year is $800,000 ($850,000 less the $50,000 decrease on the original remaining term) ^[12]. If that price does not reflect current SSP, revenue follows the blended rate: $850,000 in year three rather than $900,000, and $850,000 in year four rather than $800,000. The two treatments move $50,000 between years three and four, so the SSP conclusion has to precede the system action.

Documented system limits. Four facts constrain a design: automatic plan updates every 3 hours, a limit of 10,000 revenue elements per merge (documented for the SuiteScript merge task; the merge UI help states no cap), one effective date per merge, and a revert that works only before recognition or cost allocation exists.

Evidence quality. There are no public benchmarks of merge failure rates, close-time effects, or adoption of prospective merge among NetSuite customers, and this report does not infer any. The sources are Oracle's help pages for system behavior, ICAEW and the IFRS Foundation's TRG staff paper for IFRS 15 mechanics, PwC for SaaS interpretation, and the PCAOB standard for audit evidence principles. Partner descriptions of prospective merge, such as a ZoneBilling article about a split into a completed arrangement for revenue already recognized ^[25], describe a third-party product built on NetSuite and should not be read as Oracle documentation.

Case Study: A Worked Change Order (Hypothetical Example)

This section is a Hypothetical Example. The customer, orders, dates, prices, and SSP figures are invented to show the mechanics; the accounting conclusion is assumed, not derived.

Facts. Northwind Analytics (fictional) bought a 12-month platform subscription for $120,000 ($10,000 per month, January to December 2026) and a $15,000 onboarding service completed in the first quarter. Both sit on one arrangement, RA-1. On October 12, 2026, Northwind signs an amendment, SO-2001, that extends the platform through June 2027 and adds a Forecasting module from October 2026 to June 2027 for a combined $78,000 ($46,800 and $31,200 on the invoice lines). The SSP analysis concludes the price is below SSP, so the amendment is not a separate contract, and the reviewer concludes the remaining services are a series of distinct daily services, which supports a termination and new contract. September is closed, October is open, and no October recognition journal has posted, so the ARM effective date is October 1, 2026.

Recognized to date and residual. Through September 30, $90,000 of the platform (9 months) and all $15,000 of onboarding are recognized, for $105,000. The platform residual ratio is $90,000 divided by $120,000, or 0.75, so its residual is $30,000. Onboarding's ratio is 1.00 and its residual is zero. SO-2001 has no recognized revenue, so its residual is its full $78,000.

Updated allocation. The assumed SSP schedule is $10,000 per month for the platform and $5,000 per month for the module, so fair values are $30,000 for the platform residual, $60,000 for the six-month extension, and $45,000 for the module, totaling $135,000. The new remaining consideration of $108,000 is allocated in proportion to those fair values.

Table 3 below shows the bridge, and the control total ties at each step.

The table reconciles as follows. The original unrecognized balance ($30,000) plus new consideration ($78,000) equals the new remaining consideration ($108,000), and the three allocated amounts ($24,000, $48,000, $36,000) sum to the same $108,000. Lifetime revenue is $105,000 recognized plus $108,000 remaining, or $213,000, which equals the original $135,000 plus the $78,000 amendment. Allocation moves value between elements without changing the total: E3 rises $1,200 above its invoice amount, E4 rises $4,800, and E1 falls $6,000 from its residual, netting to zero.

What to verify in the preview. The preview total should show $108,000, the locked RA-1 should show $105,000 recognized, and E2 should carry a zero residual. October's ARM revenue is $12,000 ($8,000 platform plus $4,000 module), against $10,000 under the unmodified plan, even though the amendment was signed on October 12. The controller needs a documented position on that start-of-month convention. Had October recognition already posted before the merge, Oracle's gate would have blocked the merge until the sequencing issue was resolved.

Implications and Future Directions

For controllers. The core discipline is writing the conclusion before touching the merge page. A short template (approval, distinct analysis, SSP analysis, conclusion, ARM action, expected preview totals) keeps the technical memo and the system action tied together. Because Oracle's constraints are tied to periods, the amendments most at risk are those signed in the last days of a period, when journals may already be posted.

For ARM owners and architects. Three design choices carry long-term consequences. The Create Revenue Elements for Subscription Revisions preference is permanent once set. Unsupported plan types limit where prospective merge can be used at all. And the effective-date rule means the system date can differ from the contractual date. Where those constraints conflict with accounting policy, the options are policy alignment, a documented manual process, or custom development, and the last deserves caution because Oracle documents locked arrangements and plan truncation as part of the standard process. Integrations that create orders from a quoting or billing system should flag amendments so they route to the review queue rather than flowing straight into a merge.

For auditors and reviewers. System evidence has value when controls over its generation are tested, because the auditor must evaluate whether company-produced information is sufficient and appropriate ^[22]. A standardized evidence register makes that testing efficient and repeatable across amendments.

Future directions. Oracle's pages have changed on this topic recently, as the same-start-date rule for combined arrangements shows. Subscribe to release notes and rerun the UAT suite at each release. The accounting conclusion remains with the company's own qualified staff and advisers.

Frequently Asked Questions (FAQs)

What is a NetSuite ARM contract modification? In accounting terms, a change in scope or price approved by the parties ^[1]. In ARM terms, the change is handled by a combined arrangement or a prospective merge launched from the Merge Revenue Arrangements for Linked Sources page.

Does ASC 606 prospective treatment mean prospective merge is required in NetSuite? No. Prospective treatment is an accounting conclusion, and prospective merge is one documented way to implement it. Confirm that the locked originals and residual values match the memo before choosing it.

What is the difference between a combined arrangement and a prospective merge? A combined arrangement keeps originals editable and moves elements and plans, whereas a prospective merge locks originals and creates residual elements.

How does termination of a contract modification show up in ARM? Under a prospective merge, the originals get an effective end date and are locked, and the new arrangement carries residual values. The accounting language of "termination and new contract" corresponds in effect, but the label is not a substitute for the memo.

What about cumulative catch-up versus prospective? Catch-up adjusts revenue previously recognized, whereas a prospective merge leaves recognized revenue on the locked originals. Oracle does not map combined arrangements to catch-up treatment, so test the result.

How should change orders in construction-style or milestone contracts be handled? The same test applies. Baker Tilly notes that a modification must change scope or price ^[9], and its school example concludes that a $5 million price for an added gym reflects SSP after on-site efficiencies ^[9]. Cohen & Company adds that modifications adding distinct goods or services are separate contracts only when priced accordingly ^[10].

What are best practices for revenue arrangement modifications? Write the conclusion first, verify gates, preview and sign off, run recognition before reclassification, reconcile, and file the evidence pack.

Can a prospective merge be undone? Only before recognized revenue, reclassified deferred revenue, or contract acquisition costs exist on the merged arrangement ^[4].

Conclusion

A contract amendment is two decisions in sequence. The accounting decision, grounded in ASC 606-10-25-10 through 25-13 and IFRS 15 paragraphs 18 to 21, establishes whether the change is a separate contract, a prospective re-spread of remaining consideration, a cumulative catch-up, or a mix. The system decision then selects among documented ARM paths, each with different effects on originals, plans, and reclassification. A combined arrangement keeps originals editable; a prospective merge locks them and carries residual values forward. Neither is a default.

The gates are specific and dated: a system-set effective date, no posted recognition or reclassification journals after it, no pending plan updates, supported plan types, and a revert option that closes once recognition or costs exist. Each is an opportunity for a control: a pre-flight checklist, a signed preview, a reconciliation to the equation, and an evidence register. The fictional Northwind change order shows how $105,000 recognized, $30,000 of residual original value, and $78,000 of new consideration become $108,000 of remaining consideration with a clean plan reconciliation.

Software does not make an accounting conclusion compliant. It executes the conclusion that the accountants reach, and it does so well only when the conclusion, the configuration, and the calendar line up. Teams that document each of those three before closing the period tend to be able to explain every number afterward. Confirm every behavior in your own release, and consult a qualified accountant on any specific contract.