Audit-Ready Toolkit

Revenue recognition audit checklist

Walk through every step of IFRS 15 / ASC 606 compliance. Check off items as you go. Print it for your auditors. No jargon required.

0%

Getting started

0 of 25 items completed

Step 1

Identify the Contract

0/5
Before any revenue recognition can begin, you need to confirm a valid contract exists. Under both IFRS 15 and ASC 606, a contract must meet five specific criteria. This applies whether it's a signed MSA, a click-through ToS, or a purchase order.

Both parties have approved and committed to the contract

Confirmed the agreement is signed, clicked through, or otherwise approved by both sides. Verbal agreements count but are hard to evidence for auditors.

Each party's rights and obligations are identifiable

You can clearly state what you're delivering (software access, support, services) and what the customer owes (payment, data, cooperation).

Payment terms are identified

The contract specifies the amount, timing, and method of payment. For SaaS: monthly/annual billing, net-30 invoicing, or usage-based billing terms are all clear.

The contract has commercial substance

The arrangement will change the timing, amount, or risk of your future cash flows. Not a related-party favor or a circular transaction with no economic impact.

Collection is probable

It's more likely than not you'll collect the amounts owed. Assessed based on the customer's ability and intent to pay. Credit card on file? That helps. Customer in financial distress? Revenue waits.

⚠ Common Pitfalls

  • Treating a free trial as a contract when there's no enforceable payment obligation yet
  • Recognizing revenue on enterprise deals where the customer's creditworthiness is questionable
  • Forgetting to reassess contract criteria when terms are modified mid-term
Step 2

Identify Performance Obligations

0/5
List every promise in the contract and determine which ones are distinct performance obligations. A promise is distinct if the customer can benefit from it on its own and it's separately identifiable from other promises. This determines how many "buckets" of revenue you'll have.

Listed all promises in the contract

Documented every deliverable: software access, implementation, training, support tiers, data migration, API access, custom development, etc.

Assessed whether each promise is "capable of being distinct"

Can the customer benefit from this deliverable on its own, or with other readily available resources? If you sell it separately or competitors offer it standalone, it's probably capable of being distinct.

Assessed whether each promise is "separately identifiable"

Is this promise not highly dependent on or interrelated with other promises? If you're doing heavy customization that's deeply intertwined with the software, they may be a single combined obligation.

Checked for material rights (renewal options, free upgrades)

Does the contract give the customer a right they wouldn't get without buying the contract? Steep renewal discounts, free future upgrades, or loyalty credits can be separate performance obligations.

Documented the final list of performance obligations

Written down the definitive list of distinct performance obligations for this contract, with justification for why each is distinct (or why promises were combined).

⚠ Common Pitfalls

  • Treating "customer support" as always separate when in some contracts it's integral to the software promise
  • Missing material rights like discounted renewal options that should be a separate obligation
  • Splitting things that are highly intertwined (e.g., custom AI model + the platform it runs on)
Step 3

Determine the Transaction Price

0/5
Calculate the total amount you expect to receive. For fixed-price SaaS, this is straightforward. For variable pricing (usage-based, tiered, success fees), you'll need to estimate and apply the constraint: only include amounts where a significant revenue reversal is not highly probable.

Identified fixed vs. variable consideration components

Separated the contract price into fixed amounts (base subscription fees) and variable amounts (usage overages, performance bonuses, volume discounts, rebates).

Estimated variable consideration using the appropriate method

Used "expected value" (probability-weighted average) for contracts with a range of outcomes, or "most likely amount" for binary outcomes. Documented the method and rationale.

Applied the variable consideration constraint

Verified that including each variable amount is "highly probable" not to result in a significant revenue reversal. For uncertain usage estimates, constrained to the floor of what you're confident about.

Assessed whether a significant financing component exists

If payment is due more than 12 months after delivery (or vice versa), checked whether the time value of money is significant enough to adjust the transaction price.

Excluded amounts collected on behalf of third parties

Removed sales tax, VAT, and any pass-through amounts from the transaction price. Only amounts you're entitled to keep are included.

⚠ Common Pitfalls

  • Including speculative usage-based revenue without evidence (e.g., assuming high API usage for a new customer with no history)
  • Forgetting to reassess variable consideration estimates each reporting period
  • Ignoring volume discount thresholds that retroactively change per-unit pricing
Step 4

Allocate the Transaction Price

0/5
If you have multiple performance obligations, split the total transaction price across each one based on their relative standalone selling prices (SSP). If you only have one obligation, skip this step entirely and move to Step 5.

Determined standalone selling prices for each obligation

Used observable prices where available (prices you charge when selling the item separately). For items never sold separately, selected an estimation method.

Documented SSP estimation method (if no observable price)

Used one of: adjusted market assessment (what would the market pay?), expected cost plus margin, or residual approach (total minus known SSPs). Documented why the chosen method is appropriate.

Allocated on a relative SSP basis

Divided the total transaction price proportionally based on each obligation's standalone selling price as a percentage of the total SSP. Showed the math.

Assessed discount allocation

If the bundle is discounted vs. total SSP, determined whether the discount applies to all obligations proportionally, or to specific obligations based on observable evidence.

Allocated any variable consideration to specific obligations (if applicable)

If variable consideration relates entirely to one obligation (e.g., usage fees relate only to platform access), allocated it specifically rather than proportionally across all obligations.

⚠ Common Pitfalls

  • Using list prices as SSP when you always discount them (actual selling price matters, not sticker price)
  • Not updating SSP estimates when market conditions or your pricing changes significantly
  • Spreading usage-based variable consideration across all obligations when it clearly relates to just one
Step 5

Recognize Revenue

0/5
For each performance obligation, determine whether revenue is recognized over time or at a point in time. Most SaaS subscriptions are over time (customer receives benefit continuously). One-time deliverables like data migrations are typically at a point in time.

Determined over time vs. point in time for each obligation

Applied the three over-time criteria: (1) customer simultaneously receives and consumes benefit, (2) your work creates/enhances a customer-controlled asset, or (3) your work has no alternative use + you have a right to payment. If none apply, it's point in time.

Selected a progress measurement method (for over-time obligations)

Chose output-based (milestones, units delivered) or input-based (costs incurred, time elapsed). For SaaS subscriptions, straight-line (time-based) is most common because benefit is delivered evenly.

Identified the point of control transfer (for point-in-time obligations)

Documented when exactly the customer obtains control: acceptance of deliverable, data handover, go-live date, or when all transfer indicators are met.

Set up deferred revenue tracking

Cash received before performance creates deferred revenue (contract liability). Ensured the accounting system correctly books upfront payments as deferred and releases to revenue on the appropriate schedule.

Documented the revenue recognition schedule

Created a clear schedule showing when each dollar of revenue is recognized. For audit purposes: which months, what amounts, and under which obligation. This is what auditors will sample.

⚠ Common Pitfalls

  • Recognizing the full contract value upfront for annual SaaS deals instead of ratably over 12 months
  • Starting revenue recognition before the customer can actually access/use the software (e.g., during a setup period)
  • Using inconsistent progress measurement methods across similar contracts

Checklist complete? Go deeper.

Use the 5-Step Guide for detailed explanations and SaaS examples, or document your decisions with the Revenue Memo Template.

Open the 5-Step Guide Revenue Memo Template