How to prepare for an ASC 606 revenue audit

A revenue audit goes faster when the auditor can pick any contract and re-perform it without asking you a question. This guide covers what external auditors usually test under ASC 606, the items on a typical revenue PBC ("provided by client") list, a step-by-step way to build the file, and a 12-month schedule that ties to the cent. It is written for SaaS controllers and the outsourced teams who prepare revenue support for them. It is general guidance, not audit advice: your auditor's request list decides the scope.

What does an auditor test in ASC 606 revenue?

Auditors test whether each sampled contract follows the five-step model and whether the totals agree to the ledger and the disclosures. Revenue gets extra attention because auditing standards presume a fraud risk in revenue recognition (AU-C 240 for private companies, AS 2401 for public ones), so expect testing of judgement areas, cutoff and journal entries, not just arithmetic.

In practice the testing falls into five areas:

1. Contract existence and terms. Is there a signed contract, and do the price, term and start date match what was booked?
2. Performance obligations. Were the distinct promises identified correctly under ASC 606-10-25-19 to 25-22? See performance obligation.
3. SSP and allocation. Is each standalone selling price supported, and does the allocation follow ASC 606-10-32-28 to 32-41?
4. Timing. Is each obligation recognised over time or at a point in time, and is cutoff right at period end?
5. Presentation and disclosure. Do contract balances, disaggregation (ASC 606-10-50-5) and remaining performance obligations (50-13) agree to the schedules?

What should be on the revenue PBC list?

A revenue PBC list usually asks for the revenue policy, a contract listing that ties to the ledger, the signed contracts for a sample, SSP support, the allocation and schedule for each sampled contract, deferred revenue roll-forwards, and the disclosure workings. Having these ready before fieldwork removes most of the back-and-forth.

How do you build the file, step by step?

Build the file one contract at a time, in the order of the five-step model, and keep the evidence next to each number. Start from the signed contract, list the obligations with their clause support, attach SSP evidence, allocate, build the schedule, then reconcile the totals. Each step should be re-performable by someone who has never seen the contract.

1. Freeze the contract population. Export the contract listing at period end and agree its totals to revenue and deferred revenue in the ledger before you build anything.
2. Pull the signed documents. Use the executed versions, including every order form and amendment. Amendments need their own assessment under ASC 606-10-25-10 to 25-13 (see contract modification).
3. List the obligations with clause support. For each obligation, record the page and the verbatim excerpt from the contract that creates the promise.
4. Attach SSP evidence. Observable standalone prices first; otherwise an estimate under 32-34 (adjusted market assessment, expected cost plus margin, or residual where allowed) with the inputs shown.
5. Allocate and state the rounding rule. Exact ratios, amounts rounded to the cent, and one named line that takes the residual cent.
6. Build the schedule. Monthly amounts per obligation, with the final month absorbing the remainder so deferred revenue ends at zero.
7. Reconcile. Sum the schedules and agree them to the ledger and to the disclosure workings.

Terms pulled from contracts by any software still need a person to confirm them before they go into the file.

How do you tie the schedule to the ledger?

Tie each contract's schedule to its allocation, then tie the sum of all schedules to revenue and deferred revenue in the ledger. For a single subscription line, round the monthly amount down to the cent and let the final month absorb the remainder, so recognised revenue equals the allocated amount exactly and deferred revenue ends at $0.00.

Example: a $50,000.00, 12-month subscription obligation.

Eleven months at $4,166.66 total $45,833.26, and month 12 takes $4,166.74. The amounts are small, but a schedule that leaves a few cents in deferred revenue after the term is an easy reconciling item for a reviewer to find, and a written rule removes the question. Our post on where the rounding cent goes covers multi-line cases.

Which judgements need a memo?

Write a short memo for every judgement an auditor could reasonably challenge: SSP estimates without observable prices, bundles where a service might not be distinct, discounts placed on some obligations only (ASC 606-10-32-37), principal-versus-agent calls, and every contract modification. A memo states the facts, the guidance applied, the conclusion and who approved it.

Common memo topics for SaaS:

• SSP method and refresh cycle, including why list prices are or are not observable evidence. See the SSP allocation guide.
• Distinct assessment for implementation, onboarding and training.
• Discount allocation when it is not spread pro rata.
• Contract modifications: whether each amendment is a separate contract, a prospective change or a cumulative catch-up.
• Principal vs agent for resold third-party products.

For the most common review comments on allocation, see what SSP allocation mistakes auditors flag.

How does Soluqube help with revenue audit preparation?

Soluqube builds the allocation-and-schedule part of the file for each contract. You confirm the obligations and stated prices. It returns a relative SSP allocation in integer arithmetic that ties to the contract price, a schedule whose final period absorbs the remainder so deferred revenue ends at $0.00, a page and verbatim excerpt for each obligation, and a SHA-256-hashed export a reviewer can re-check.

What it does today:

• Allocation and schedule in integer (BigInt) arithmetic, rounded to the cent, deterministic: the same inputs give the same numbers and the same hash.
• Clause evidence per obligation: page and verbatim excerpt; on uploaded PDFs with a text layer, the cited line is highlighted. Scanned PDFs without a text layer are refused.
• Human confirmation: contract terms are extracted heuristically and must be confirmed before they drive the numbers.
• Ind AS 115: for INR contracts, 18% GST is kept out of the transaction price. US contracts carry no GST.

What it does not do: it does not account for contract modifications (amendments are flagged for manual review), and it does not replace your policy, memos or the auditor's judgement.

To try it on your own contracts, send three of your hardest bundled contracts through the design partner programme for a free 3-contract workpaper, or re-perform an allocation in the SSP allocation calculator. The sample SSP workpaper shows the finished structure. Founding prices for the first 10 customers are on pricing.