ASC 606 Modifications: Why Revenue Recognition Breaks

The CFO question that ends most rev rec automation conversations: "Does the tool handle modifications?"

The answer from the vendor is always yes. The answer from the senior accountant who runs the close is more nuanced. Initial bookings — a new contract with a fixed price and a single performance obligation — are solved across the category. Modifications are where the tool stops doing the work, and the rev rec analyst spends Day 3 of close rebuilding the schedule in Excel.

For the broad walkthrough of the ASC 606 standard and the five failure points in a manual revenue recognition process, start with the pillar: ASC 606 revenue recognition for mid-market companies. This piece is the modifications-specific companion — it walks through the three modification scenarios that break automation, the ASC 606 treatment for each, and the audit-trail question a CFO should be asking before signing off on the close.

What rev rec tools do well

For context, before getting to where they break:

If your contract portfolio is mostly fixed-price annual renewals with no mid-term changes, the tool earns its keep on day 1 and you stop here.

Where rev rec breaks: the three modification scenarios

Scenario 1: A modification that triggers a combined-contract reallocation

A customer signs a $120K ARR contract in January for Product A. In month 7, they expand to add Product B for an additional $60K, extend the term 6 months, and negotiate a retroactive discount on the original bundle.

What the CFO should ask: when the tool defaults to separate-contract treatment, who reviews and approves the alternative treatment when it is wrong?

Scenario 2: An SSP reassessment that should trigger a retroactive reallocation

SSP has to be assessed periodically. When the company changes its pricing model — even at the portfolio level — prior-period allocations for open contracts should be reviewed.

Tools store SSP as a config field. When the pricing list updates in Q2, the new SSP applies to contracts booked in Q2 and forward. Contracts booked in Q1 don't get their allocations reviewed unless someone flags them manually.

The accounting question: under what circumstances does an SSP change trigger a retroactive reallocation of open contracts? Generally only on modification events or when the original allocation is determined to have been wrong. But the operational question is harder: which contracts should be reviewed when SSP changes, and who decides?

In most rev rec implementations, the answer is "nobody — until the auditor asks at year-end." That answer creates a control gap.

What the CFO should ask: when SSP policy updates, what is the workflow to identify and review contracts that might require reallocation?

Scenario 3: Variable consideration true-ups that need diagnostic context

Usage-based pricing, performance bonuses, milestone payments — these require estimating variable consideration at contract inception and true-ing up as more information is available.

Booking the true-up journal entry is straightforward. The diagnostic work — which contracts need a true-up, how much, and why — is where the rev rec analyst spends real time.

What the CFO should ask: for the contracts with variable consideration, what is the workflow to identify which need true-ups at quarter-end, and how is the supporting analysis preserved for audit?

The audit trail problem behind all three

The common failure mode across these three scenarios is not the math. The math is doable. It is the audit trail.

When a modification is treated as a combined-contract reallocation, the auditor will want to see: the pre-modification schedule, the new schedule, the rationale for the treatment, the SSP applied, the discount rate used (if relevant), and the approver. When SSP triggers a reallocation, the auditor wants the version history of the SSP policy, the contracts that were reviewed, and the conclusions documented. When variable consideration is trued up, the auditor wants the original estimate, the actuals, the true-up calculation, and the memo explaining the variance.

Most rev rec tools store the current state. They do not preserve the history. The audit trail lives in Word memos, SharePoint folders, and the senior accountant's inbox.

This is what the CFO should care about. Not whether the tool can recognize revenue. Whether the tool can defend the revenue number under audit. The same control-gap pattern shows up across the close — as outlined in AP software as a material weakness risk, where undocumented manual workarounds are the common thread.

The 4-question rev rec audit-ready test

If you are evaluating where your rev rec automation is doing the work and where it is not, ask these four:

Two or more "no" answers mean modifications are running in Excel. The tool is automating the easy half.

The close is downstream. Fix the modification workflow.

Most rev rec implementations focus on getting the initial booking right — the five-step ASC 606 model applied at contract inception. The harder, longer-tail work is what happens when contracts change — which they always do. Combined-contract reallocations, SSP updates, variable consideration true-ups. Each one is a discrete event the tool should treat as a first-class object with its own audit trail.

At Cadel we built revenue recognition automation around contract intelligence and modification handling, not just the day-1 schedule. The tool reads the contract document and the amendment. It proposes the ASC 606 treatment, lets the accountant approve or override, and preserves the audit trail from inception through every modification.