How to recognize revenue for a mid-term upgrade on a multi-year contract
A mid-term upgrade is a contract modification under ASC 606. Worked journal entries for a 24-month contract upgraded in month nine.
Part of the revenue recognition guide.
A mid-term upgrade on a multi-year contract is a contract modification under ASC 606, and for a typical SaaS subscription it is accounted for prospectively. You treat the upgrade as if the old contract ended and a new one began: take the consideration not yet recognized from the original contract, add the new consideration from the upgrade, and recognize the total over the remaining term. The upgrade is a separate contract only if it adds distinct services priced at their standalone selling price. A cumulative catch-up applies only when the remaining services are not distinct from those already delivered.
Those three paths produce three different revenue schedules for the same deal. This guide works through a 24-month contract upgraded in month nine, with full journal entries for the prospective treatment and the cumulative catch-up treatment, so you can see exactly where the numbers diverge.
Key takeaways
• A mid-term upgrade is a contract modification when both parties approve a change in scope, price, or both (ASC 606-10-25-10).
• There are three possible treatments: a separate contract (ASC 606-10-25-12), a prospective termination-and-new-contract (ASC 606-10-25-13(a)), or a cumulative catch-up (ASC 606-10-25-13(b)).
• Most SaaS upgrades are prospective, because a subscription is a series of distinct monthly service periods and an upgrade priced below standalone selling price fails the separate-contract test.
• In the worked example, prospective treatment gives $13,000 a month for the last 16 months, while cumulative catch-up books $16,000 on the modification date and $12,000 a month after it.
• Both treatments recognize the same $288,000 in total; only the timing differs, which is why auditors test the classification decision first.
• Loopfour, the deterministic finance workflow automation platform, rebuilds the revenue schedule from the amended contract and routes the modification classification to a named approver before anything posts.
Is a mid-term upgrade a contract modification?
Yes. An upgrade is a contract modification under ASC 606 when the parties approve a change in the scope or price of the contract, or both. ASC 606-10-25-10 defines a modification this way, and it covers upgrades, added seats, tier changes, term extensions, and price changes. The modification exists once it is approved and enforceable, even if the price change is still being finalized.
The next question is which of three treatments applies. The decision turns on two tests: are the added goods or services distinct, and are they priced at standalone selling price? If you need a refresher on distinct performance obligations, see what ASC 606 is and how the five steps work.
| Treatment | When it applies | What happens to the original schedule | Common SaaS example |
|---|---|---|---|
| Separate contract (606-10-25-12) | Adds distinct goods or services and the price increase reflects their standalone selling price | Unchanged; the new contract gets its own schedule | Customer adds 50 seats at the current list price |
| Prospective (606-10-25-13(a)) | Remaining goods or services are distinct from those already transferred | Unrecognized consideration plus new consideration is spread over the remaining term | Customer moves from Growth to Enterprise tier at a negotiated price |
| Cumulative catch-up (606-10-25-13(b)) | Remaining goods or services are not distinct and form part of a single partially satisfied performance obligation | Transaction price and progress are updated, and the difference is booked on the modification date | Scope added to a single combined implementation and platform obligation |
ASC 606-10-25-13(c) allows a combination of the two when a contract has some remaining obligations that are distinct and some that are not.
The worked example: a 24-month contract upgraded in month nine
Here are the facts for every scenario below. A customer signs a 24-month contract for the Growth tier starting January 1, Year 1, at $10,000 a month. Total contract value is $240,000, billed annually in advance: $120,000 on January 1 of each year. The contract is non-cancellable.
On September 1, Year 1, the start of month nine, the customer upgrades to the Enterprise tier for the remaining 16 months. Enterprise has a standalone selling price of $15,000 a month, but the customer negotiates an upgraded price of $13,000 a month, a $3,000 monthly increase. The added consideration is $3,000 × 16 = $48,000. Billing: a prorated $12,000 upgrade invoice on September 1 for September to December, then $156,000 on January 1, Year 2.
By August 31, eight months have passed. You have recognized $80,000 of revenue and hold $40,000 of deferred revenue from the Year 1 invoice.
Why the upgrade is not a separate contract
The upgrade fails the separate-contract test in ASC 606-10-25-12 on price. The Enterprise tier replaces the Growth tier rather than adding to it, and the $3,000 increase is well below the $5,000 difference in standalone selling price. ASC 606 allows "appropriate adjustments" to standalone selling price, such as a discount reflecting selling costs you avoid with an existing customer. In this example, the $2,000-a-month gap is a negotiated commercial discount, not an avoided-cost adjustment, so the price does not reflect standalone selling price.
If the facts were different (say the customer added a separate analytics module at its full list price of $5,000 a month), the add-on would be a separate contract. You would leave the original $10,000-a-month schedule alone and recognize the new $80,000 contract over 16 months.
Prospective treatment: the default for SaaS upgrades
Under ASC 606-10-25-13(a), you account for the upgrade as a termination of the old contract and the creation of a new one. This applies because each remaining month of service is distinct from the months already delivered. A SaaS subscription is a series of distinct service periods, so remaining months are distinct by design.
The new contract's transaction price is the consideration not yet recognized from the original contract plus the consideration promised in the modification. Amounts already invoiced but not yet recognized are included.
| Component | Amount |
|---|---|
| Original contract value | $240,000 |
| Less: revenue recognized January to August | ($80,000) |
| Consideration not yet recognized | $160,000 |
| Plus: consideration from the upgrade | $48,000 |
| New transaction price for the remaining 16 months | $208,000 |
| Monthly revenue, September Year 1 to December Year 2 | $13,000 |
Journal entries under prospective treatment
Every entry below balances, and deferred revenue returns to zero at the end of each billing year.
| Date | Account | Debit | Credit |
|---|---|---|---|
| Jan 1, Year 1 | Accounts receivable | $120,000 | |
| Deferred revenue | $120,000 | ||
| Each month-end, Jan to Aug, Year 1 (x8) | Deferred revenue | $10,000 | |
| Subscription revenue | $10,000 | ||
| Sep 1, Year 1 (upgrade invoice) | Accounts receivable | $12,000 | |
| Deferred revenue | $12,000 | ||
| Each month-end, Sep to Dec, Year 1 (x4) | Deferred revenue | $13,000 | |
| Subscription revenue | $13,000 | ||
| Jan 1, Year 2 | Accounts receivable | $156,000 | |
| Deferred revenue | $156,000 | ||
| Each month-end, Year 2 (x12) | Deferred revenue | $13,000 | |
| Subscription revenue | $13,000 |
Deferred revenue check for Year 1: $40,000 at August 31, plus the $12,000 upgrade invoice, minus four months at $13,000 ($52,000), equals zero at December 31. Total revenue: $80,000 + $52,000 + $156,000 = $288,000, which equals the $240,000 original price plus the $48,000 upgrade.
For the mechanics of the underlying monthly release, see our deferred revenue journal entries for an annual SaaS contract.
Cumulative catch-up treatment: when the remaining service is not distinct
Under ASC 606-10-25-13(b), you treat the upgrade as part of the existing contract and book the effect on revenue to date immediately. This applies only when the remaining goods or services are not distinct and form part of a single performance obligation that is partially satisfied. It is common in construction and custom development. It is uncommon for standard SaaS.
For the same numbers to fit, change one fact. Suppose the contract is a heavily customized platform where implementation and hosting were combined into a single performance obligation, measured by time elapsed over the 24-month term. The upgrade adds scope to that same combined obligation, and the term does not change.
| Component | Amount |
|---|---|
| Updated transaction price ($240,000 + $48,000) | $288,000 |
| Progress at September 1 (8 of 24 months) | 33.3% |
| Cumulative revenue that should be recognized ($288,000 × 8/24) | $96,000 |
| Less: revenue already recognized | ($80,000) |
| Cumulative catch-up on September 1 | $16,000 |
| Remaining revenue ($288,000 − $96,000) over 16 months | $12,000 a month |
Journal entries under cumulative catch-up
Billing is unchanged, so the catch-up and the lower monthly revenue create a contract asset at year-end. Revenue now runs ahead of billing in December, Year 1.
| Date | Account | Debit | Credit |
|---|---|---|---|
| Jan 1 to Aug 31, Year 1 | Same as prospective: $120,000 invoice and eight releases of $10,000 | ||
| Sep 1, Year 1 (upgrade invoice) | Accounts receivable | $12,000 | |
| Deferred revenue | $12,000 | ||
| Sep 1, Year 1 (catch-up) | Deferred revenue | $16,000 | |
| Subscription revenue | $16,000 | ||
| Month-end Sep, Oct, Nov, Year 1 (x3) | Deferred revenue | $12,000 | |
| Subscription revenue | $12,000 | ||
| Dec 31, Year 1 | Contract asset | $12,000 | |
| Subscription revenue | $12,000 | ||
| Jan 1, Year 2 | Accounts receivable | $156,000 | |
| Contract asset | $12,000 | ||
| Deferred revenue | $144,000 | ||
| Each month-end, Year 2 (x12) | Deferred revenue | $12,000 | |
| Subscription revenue | $12,000 |
Deferred revenue check: $40,000 + $12,000 − $16,000 − $36,000 = $0 at November 30, so December's revenue becomes a contract asset. Total revenue: $80,000 + $16,000 + $48,000 + $144,000 = $288,000, the same total as the prospective method.
Prospective vs cumulative catch-up: side by side
The two treatments recognize the same $288,000 over the contract, but they move revenue between periods. That timing difference is why the classification decision needs documentation and approval.
| Period | Prospective | Cumulative catch-up | Difference |
|---|---|---|---|
| Jan to Aug, Year 1 | $80,000 | $80,000 | $0 |
| Sep to Dec, Year 1 | $52,000 | $64,000 | +$12,000 |
| Year 1 total | $132,000 | $144,000 | +$12,000 |
| Year 2 total | $156,000 | $144,000 | −$12,000 |
| Contract total | $288,000 | $288,000 | $0 |
Picking the wrong method misstates both years. For a standard SaaS upgrade, booking a catch-up pulls revenue forward into the year of the upgrade, which is exactly the pattern auditors look for.
Where mid-term upgrades break in practice
Upgrades rarely break on the accounting. They break when the amendment never reaches the revenue schedule. The CRM records a new opportunity, billing issues a prorated invoice, and the revenue schedule keeps running at the old rate until someone notices at quarter-end.
• The upgrade is booked as a new, separate contract because the CRM created a new opportunity, even though the price is below standalone selling price.
• The old schedule is not terminated, so revenue double-counts for the overlap months.
• Prorated credits are recognized as revenue instead of being folded into the new transaction price.
• The ERP schedule is never updated. A closed-won upgrade in Salesforce does not always update the NetSuite revenue arrangement, as we cover in why Salesforce closed-won deals don't create NetSuite revenue schedules.
Book a workflow review to see how your upgrades flow from the signed amendment to the schedule today.
How to choose a process for contract modifications
Choose a process that classifies each modification once, by rule, with approval, and then rebuilds the schedule automatically. The judgment (separate, prospective, or catch-up) belongs to your team. The arithmetic and the posting should never depend on who is on shift.
Spreadsheets handle a few modifications a quarter. Horizontal automation platforms can move amendment data between systems and are flexible, but they do not know that a below-SSP tier change fails ASC 606-10-25-12. An AI agent that decides the treatment at runtime gives you a different answer on a different day, and your auditor will notice.
Loopfour runs predefined, programmatic steps instead. The Contract Agent reads the signed amendment under a confidence threshold and extracts the effective date, new price, and scope; low-confidence fields go to a reviewer. A deterministic rule proposes the treatment from your approved SSP table, a controller approves it in Slack, and the schedule, entries, and execution tree follow. A fractional CFO firm running a dozen clients gets the same treatment for the same facts on every client.
Frequently asked questions
How do you account for a SaaS upgrade under ASC 606? Most SaaS upgrades are accounted for prospectively under ASC 606-10-25-13(a). You add the consideration not yet recognized from the original contract to the new consideration from the upgrade, and recognize the total over the remaining service period. The upgrade is a separate contract only if it adds distinct services priced at standalone selling price.
When is a contract modification a separate contract? A modification is a separate contract when it adds distinct goods or services and the price increases by an amount that reflects their standalone selling price, with appropriate adjustments. Adding seats or a new module at list price often qualifies. Replacing a tier at a discounted price usually does not.
When do you use a cumulative catch-up for a contract modification? You use a cumulative catch-up when the remaining goods or services are not distinct from those already transferred and form part of a single, partially satisfied performance obligation. It is common in construction and custom development, and uncommon for standard SaaS subscriptions.
Does an upgrade change the remaining performance obligation? Yes. After an upgrade, the remaining performance obligation equals the new transaction price not yet recognized. In the example, remaining performance obligations on September 1 are $208,000 under the prospective method, before any revenue is recognized for September.
What about a downgrade mid-term? A downgrade is also a contract modification. For a SaaS subscription, a downgrade that reduces future service and price is usually accounted for prospectively: the unrecognized consideration, adjusted for the price reduction, is spread over the remaining term. A credit that relates to past performance, such as a concession for an outage, is variable consideration rather than a modification.
Conclusion
Revenue recognition for a mid-term upgrade on a multi-year contract comes down to one classification and one recalculation. For standard SaaS, the answer is almost always prospective: unrecognized consideration plus new consideration, spread over the remaining term. The risk is not the rule. It is an amendment that never reaches the schedule, or a treatment that changes depending on who books it.
Tell us the one workflow your team dreads. We will show it running: deterministic, permissioned, and auditable.
Book a demo.
Sources
• Deloitte DART, Revenue Roadmap, 9.2 Types of contract modifications
• FASB, ASU 2014-09, Revenue from Contracts with Customers (Topic 606)
Related reading
• How to automate ASC 606 revenue recognition without losing the audit trail
• Contracted ARR, live ARR, and RPO: the SaaS metrics that come straight from your contracts
• How to build a deferred revenue waterfall schedule
• How to automate contract-to-cash, step by step
Sources
- Financial Accounting Standards Board, ASU 2014-09, Revenue from Contracts with Customers (Topic 606) (opens in a new tab).