Revenue Recognition Review

By Nupur Mittal

Co-founder at OCTA — works with accounting firms on month-end close and reconciliation automation.

A revenue recognition review confirms that revenue is recorded in the correct period and the correct amount under ASC 606 (US GAAP) or IFRS 15 (international) — the converged five-step model that governs when a company can recognize revenue from a contract with a customer. It works through significant contracts under the five-step model, tests cut-off on period-end invoices, and reconciles deferred and unbilled revenue schedules. This page walks through the full review step by step, the red flags a careful reviewer watches for, and how accounting firms run the review faster with OCTA Flow while a human approves every adjustment.

Why revenue recognition reviews matter, and where they go wrong

Revenue is the number every stakeholder looks at first — investors, lenders, boards, and buyers in a diligence process all anchor to the top line before anything else. That makes it the account most exposed to pressure: a sales team wants a deal booked this quarter, a CFO wants a smoother trend line, and a bundled contract with multiple deliverables creates real room for judgment about when revenue should hit the P&L. ASC 606 and IFRS 15 exist to remove that ambiguity by tying recognition to a specific, auditable event — the transfer of control over a good or service — rather than to when cash arrives or an invoice goes out.

For a firm, the review is hard because it isn't mechanical in the way a reconciliation is. Each significant contract has to be read, its performance obligations identified, and a judgment made about whether revenue should be recognized at a point in time or over time. Add subscription contracts with implementation fees, bundled software-plus-services deals, and multi-year agreements with variable pricing, and a small misstep — booking an implementation fee before go-live, or letting deferred revenue sit unreleased — becomes a restatement risk rather than a rounding error. The goal of the review is a documented, defensible position on every material contract, with cut-off, deferred revenue, and unbilled revenue all tying out cleanly — not a assumption that "revenue looks about right."

The revenue recognition review process, step by step

A rigorous revenue recognition review follows a consistent sequence. The steps below are the full procedure OCTA Flow executes; they also stand alone as a best-practice process any firm or finance team can follow.

1. Apply the five-step model to each significant contract. Read the contract in full — including any amendments — before applying the model:

• Step 1 — Identify the contract. Confirm there is a written or oral agreement, commercial substance, that collectibility is probable, and that each party's rights and payment terms can be identified.
• Step 2 — Identify the performance obligations. List every distinct good or service promised. A promise is distinct if the customer can benefit from it on its own and it's separately identifiable from the other promises in the contract.
• Step 3 — Determine the transaction price. Note fixed amounts, variable consideration (constrained to the extent it's probable it won't reverse), any significant financing component, and non-cash consideration.
• Step 4 — Allocate the transaction price. Allocate the price across performance obligations based on relative standalone selling price (SSP). Flag bundled arrangements where the SSP allocation could shift revenue between periods.
• Step 5 — Recognize revenue as each obligation is satisfied. Point-in-time obligations recognize revenue when control transfers to the customer; over-time obligations use an appropriate progress measure — an output method (units delivered, milestones reached) or an input method (costs incurred, time elapsed).

2. Test cut-off on period-end invoices. For invoices issued in the last 30 days of the period, ask: when was the performance obligation actually satisfied, and was revenue recognized in that same period? Flag any invoice where the service delivery date differs significantly from the invoice date — the classic sign of revenue booked in the wrong period.

3. Review the deferred revenue schedule. Verify the opening balance, additions from new billings, amounts recognized during the period, and the resulting closing balance. Confirm revenue is being released as — and only as — performance obligations are satisfied. Flag any deferred revenue item more than 12 months old, which can indicate a stalled implementation or a recognition failure rather than a normal multi-year contract term.

4. Review the unbilled (accrued) revenue schedule. Confirm the performance obligation has actually been satisfied and the amount is reliably measurable before revenue is accrued ahead of billing. Verify the invoice has been — or will imminently be — issued. Flag anything unbilled for more than 60 days without a documented explanation.

5. Analyze the general ledger for revenue anomalies. Scan revenue GL activity for credit entries to revenue accounts (potential reversals), journal entries posted directly to revenue without a corresponding invoice or deferred-revenue release, and large revenue entries at period end that lack supporting documentation. These are the entries most associated with manual override and fraud risk.

Applying the 5-step model: a worked example

Here's how the model plays out on a real contract. A firm signs a one-year enterprise software agreement: a $60,000 implementation fee (a one-time setup) bundled with a $180,000 annual subscription ($15,000/month), for total contract value of $240,000.

Step 1 — Identify the contract. Signed master service agreement, 12-month term, collectibility probable, payment terms net-30 monthly. Contract exists.

Step 2 — Identify the performance obligations. Two distinct promises: (a) implementation and configuration, which the customer benefits from on its own once delivered, and (b) the software subscription, delivered continuously over the term. These are separately identifiable, so they're accounted for as two performance obligations rather than one bundled obligation.

Step 3 — Determine the transaction price. $240,000 total, fixed consideration, no variable component, no significant financing component (billing is monthly, in line with delivery).

Step 4 — Allocate the transaction price. Standalone selling price for implementation is $60,000; for the subscription, $180,000 ($15,000 × 12). Since the contract price matches the sum of standalone prices, no reallocation is needed — $60,000 allocates to implementation, $180,000 to the subscription.

Step 5 — Recognize revenue. Implementation is a point-in-time obligation: the customer doesn't benefit from a half-finished setup, so the full $60,000 is recognized on go-live, not on contract signing and not ratably over the term. The subscription is an over-time obligation, recognized ratably at $15,000 per month as the software is made available.

Where it goes wrong: Say go-live actually occurred on March 15, but the $60,000 implementation fee was recognized in February, when the invoice was issued, because the sales team wanted the deal to land in Q1. That's early recognition — revenue booked before the performance obligation was satisfied. The correcting entry reverses it out of the wrong period and books it in the right one:

The net effect: February revenue drops by $60,000, March revenue picks it up, and the deferred revenue balance bridges the gap in between — which is exactly what the deferred revenue roll-forward in the review is designed to catch.

Key controls and red flags

The difference between running the five-step model once and running a reliable review is what you watch for across every contract, every period. A careful reviewer flags:

• Revenue recognized before the performance obligation is satisfied — early recognition, the most serious and most common finding
• Revenue not recognized after the performance obligation is satisfied — late recognition, which understates the period
• Variable consideration that hasn't been adequately constrained — an overstatement risk if the estimate is too aggressive
• Bundled arrangements with no documented SSP allocation — the allocation basis should be evidenced, not assumed
• Deferred revenue aging more than 12 months — may signal a stalled delivery or a recognition failure, not just a long contract term
• Unbilled revenue outstanding more than 60 days without explanation
• Manual journal entries posted directly to revenue accounts — a fraud and override risk that bypasses the normal invoice-to-revenue flow
• Long-term contracts recognized on a percentage-of-completion basis without progress documentation — the progress measure needs support, not just an estimate

Catching these on every material contract, every period, is what turns the review from a checkbox on the close calendar into a genuine control over the top line.

What a completed revenue recognition review produces

A finished review isn't just a checked box on the five-step model — it's a documented workpaper a reviewer can sign off on and an auditor can follow. A complete revenue recognition review package includes:

How OCTA Flow automates revenue recognition review

OCTA Flow reads the contracts, applies the model, and runs the cut-off and roll-forward testing for you — and leaves the judgment calls, and the sign-off, with your team. The workflow mirrors the process above:

1. Pick the Revenue Recognition Review Skill. Flow already knows the full procedure: apply the five-step model to each significant contract, test cut-off on period-end invoices, roll forward deferred revenue, review unbilled revenue, and scan the GL for anomalies.
2. Connect your data. Point Flow at the accounting system and contract repository, or upload the period's files — revenue GL detail, contract documentation, period-end invoices, and the deferred and unbilled revenue schedules if you keep them.
3. Run. Flow reads each contract, identifies the performance obligations, determines and allocates the transaction price, and tests whether recognition timing matches when control actually transferred — then rolls forward the deferred and unbilled revenue balances.
4. Review findings by severity. Instead of re-reading every contract from scratch, Flow surfaces only the exceptions — ranked by severity, each with a plain-English explanation and a recommended action: post the correcting entry, escalate to technical accounting, notify the external auditor, or request missing contract documentation. Your team works the exceptions, not every clause.
5. Sign off. Once recognition ties to the model and every adjustment is approved, Flow assembles the workpaper with the full audit trail intact.

The result: the mechanical parts of the review — reading schedules, rolling forward balances, checking cut-off dates — happen in a fraction of the time, and your people spend their hours on the handful of contracts where recognition timing is genuinely a judgment call.

Control and trust: Flow proposes, you approve

This is what matters most to a firm putting its name on a client's revenue line: OCTA Flow never writes to your books on its own. Every correcting entry, every reallocation, and every disclosure draft is a proposal that a person reviews and confirms before anything is posted. Flow does the reading and the modeling and shows its reasoning; a person makes the call.

That control model runs through the whole review:

• Findings, not silent changes. Flow raises what it found and what it recommends on each contract — you decide whether to resolve it, escalate it, or accept it with documented judgment.
• Severity and escalation built in. Early recognition and bill-and-hold issues are flagged as critical and routed toward escalation or auditor notification, rather than quietly logged as one line among many.
• A complete audit trail. Every contract read, every allocation, every proposed entry, approval, and override is logged, so the review is fully traceable back to the source contract.

You get the speed of automation on the mechanical review work, with the accountability of human sign-off on every judgment — exactly what a revenue recognition review demands under auditor scrutiny.

What the review draws on

To run a revenue recognition review, Flow uses the same sources a preparer already works from:

• Revenue GL detail — the general-ledger revenue entries for the period (required)
• Contract documentation — the significant contracts under review, with performance obligations and payment terms (required)
• A sample contract — the master service agreement or equivalent, read in full to ground the five-step analysis (required)
• Period-end invoice detail — invoices issued in the last 30 days of the period, for cut-off testing (required)
• Deferred revenue schedule — the roll-forward of deferred balances, if maintained (optional)
• Unbilled revenue schedule — accrued revenue not yet invoiced, if maintained (optional)

Flow works from whatever your client has connected — it matches each input by its purpose, so it doesn't matter what the files are named or which contract management or accounting system they came from.

Related skills and terms

Frequently Asked Questions

What is ASC 606? ASC 606 is the US GAAP revenue recognition standard, "Revenue from Contracts with Customers." It requires revenue to be recognized when control of a promised good or service transfers to the customer, using a five-step model, rather than simply when cash is received or an invoice is issued.

What is IFRS 15? IFRS 15 is the international equivalent of ASC 606, issued by the IASB. The two standards were developed jointly and share the same five-step model and core principles, so a contract analyzed under one framework generally reaches the same recognition conclusion under the other, though some disclosure and narrow-scope details differ.

What is the revenue recognition 5-step model? The five steps are: (1) identify the contract with a customer, (2) identify the performance obligations, (3) determine the transaction price, (4) allocate the transaction price to each performance obligation, and (5) recognize revenue as each obligation is satisfied — either at a point in time or over time.

What is revenue cut-off testing? Cut-off testing checks invoices issued near period-end to confirm the performance obligation was actually satisfied in the period revenue was recognized. It's the primary test for catching revenue booked in the wrong period — either pulled forward to hit a target or pushed back to smooth a result.

What is deferred revenue? Deferred revenue is cash billed or collected for goods or services not yet delivered. It sits on the balance sheet as a liability and is released to the income statement as revenue only as the underlying performance obligation is satisfied — which is what a deferred revenue roll-forward is designed to verify.

Can revenue recognition review be automated? The mechanical parts — reading contracts, applying the five-step model consistently, testing cut-off, and rolling forward deferred and unbilled revenue — can be automated and reviewed. The judgment calls on standalone selling price, variable consideration, and progress measures stay with your team. That's the model OCTA Flow uses.

Does OCTA Flow post revenue adjustments directly to my accounting system? No. Flow proposes every correcting entry and reallocation; a person on your team reviews and approves before anything is posted to the books. Nothing is written automatically.

See how firms run faster, better-documented revenue recognition reviews with human sign-off → start a 30-day OCTA Flow trial.