Contract modifications are where SaaS revenue schedules quietly go wrong. Not because the accounting is obscure, but because modifications happen constantly, get recorded in the CRM rather than the ledger, and each type needs different treatment.
Here is the practical version.
AASB 15 gives you three ways to account for a modification, and which one applies depends on what changed.
Treat it as a separate contract. This applies when the modification adds distinct goods or services and the price increase reflects their standalone selling price. A customer buying twenty more seats at the same rate mid-term is the clean example. The original schedule is untouched; the addition gets its own.
Terminate the old contract and create a new one. This applies when the remaining goods or services are distinct from those already delivered, but the pricing does not reflect standalone selling price — for example, extra seats at a discount. You take the unrecognised portion of the original, combine it with the new consideration, and recognise the total across the remaining term prospectively.
Treat it as part of the original contract. This applies when the remaining goods or services are not distinct — typically a single subscription obligation being modified. Here you make a cumulative catch-up adjustment to revenue, which can produce a lumpy month.
The distinction between the second and third treatments is where most errors happen, and it turns on whether what remains is distinct — not on the commercial framing.
Mid-term upgrades with co-terminus dates. The customer adds a module in month seven, expiring with the original contract. Is the module distinct? At standalone price? The answer determines whether you get a clean new schedule or a catch-up.
Early renewals. A customer renews in month ten of twelve, at a new rate, for a new term starting immediately. You now have two months of the original contract being superseded.
Downgrades and partial cancellations. Reducing scope mid-term is a modification, and if there is a termination penalty, that has its own treatment.
Service credits. An SLA breach credit is usually variable consideration — a reduction of the transaction price — rather than an expense. Many teams book it as a cost, which overstates revenue.
Free extensions as a retention tactic. Adding two free months to keep an unhappy customer changes the transaction price over a longer period, and is generally a discount rather than free service.
Each modification requires: identifying the type, recalculating the remaining transaction price, reallocating across obligations, adjusting the schedule prospectively or cumulatively, and retaining the reasoning.
In a spreadsheet, this is a person remembering to do five things correctly, on a schedule that may already have been rebuilt twice. The failure is almost never a single dramatic error. It is small drift, in one direction, accumulating.
The tell is a deferred revenue balance that no longer reconciles to the open contract population — usually noticed when someone tries to tie it out for the first time.
Systems that manage the contract lifecycle and derive the revenue schedule from it avoid this by construction: the modification is recorded once, and the schedule follows.
Whatever system you use, three rules help:
Modification handling is one of the areas where implementations most often fall short, because it is invisible during a demo and unavoidable in production. We configure it against your actual contract patterns — including the awkward ones.
If your deferred revenue balance is difficult to tie out, start there. It is usually the fastest diagnostic of whether the underlying process is sound.