ASC606 Revenue Accounting

The Problem

For mid-market professional services and SaaS companies, revenue recognition under ASC 606 is not a single calculation — it is a chain of document-dependent judgments that must be repeated for every contract, every period. A controller at a 150-person services firm may manage 40–80 active SOWs simultaneously, each with its own transaction price, performance obligation schedule, and billing milestone. Manually tracing from an MSA through a SOW to a timesheet and then to an acceptance record takes, on average, two to three days per month-end close cycle, and that estimate holds only when no documents are missing or amended.

The problem compounds with contract variety. A single client may have a fixed-fee website replatform bundled with a 12-month post-launch support retainer — two distinct performance obligations under ASC 606-10-25-19 that must be allocated transaction price using relative standalone selling prices (SSP). Treating the bundle as one obligation overstates near-term revenue and understates the deferred liability on the balance sheet. In a manual spreadsheet environment, that allocation is typically done once at contract inception and rarely revisited when a change order arrives.

Variable consideration adds a further layer. Time-and-materials contracts with performance bonuses require controllers to assess whether the bonus amount is probable of not reversing under the constraint in ASC 606-10-32-11 — and that assessment must be refreshed each reporting period. Without a systematic link between the acceptance record and the originating SOW, controllers either recognize the bonus too early (violating the constraint) or hold it too long (understating revenue). Neither error is immaterial at $500K+ contract values.

At scale, the manual process introduces four failure modes that are structurally difficult to prevent: incorrect POB identification, inconsistent progress measurement methods, missed cut-off on late-uploaded acceptance records, and undetected loss contracts when timesheet hours breach fixed-fee estimates. Each failure mode has a direct audit exposure under PCAOB AS 2401 or a restatement risk under ASC 250.

Why It Matters: Context

ASC 606, Revenue from Contracts with Customers (FASB ASC Topic 606), replaced ASC 605 for public companies in 2018 and for most private companies by 2019. Its five-step model — identify the contract, identify performance obligations, determine the transaction price, allocate the transaction price, and recognize revenue when (or as) an obligation is satisfied — is procedurally clear but evidence-intensive. Step 2 alone requires reading every contract to assess whether promised goods or services are distinct under ASC 606-10-25-19, a judgment that depends on both the contract terms and observable market evidence of standalone selling prices. Step 5 requires selecting and consistently applying either an input method (e.g., labor hours) or an output method (e.g., milestone completion) per ASC 606-10-55-16 through 55-21.

For mid-market companies — typically those with $10M–$250M in service revenue, no dedicated technical accounting team, and contracts stored across a shared drive, a CRM, and an email inbox — the evidentiary chain is fragile. Timesheets live in a project management tool. MSAs and SOWs are PDFs signed via DocuSign. Acceptance records arrive by email and are often uploaded to accounting systems days after execution. None of these systems talk to each other natively, which means a controller must manually cross-reference four or more document types to close a single contract's revenue schedule correctly.

The regulatory consequence of getting this wrong is not theoretical. For SEC registrants, a revenue recognition error that is quantitatively or qualitatively material triggers a restatement under ASC 250-10 and potential comment letters from the SEC's Division of Corporation Finance. For private companies seeking acquisition financing or audit opinions, an incorrect deferred revenue balance or an unrecognized loss contract will result in audit adjustments, a qualified opinion, or, in due-diligence contexts, a purchase price reduction. The AICPA's Audit and Accounting Guide: Revenue Recognition specifically identifies multi-element arrangements and variable consideration constraints as high-risk areas requiring documented, reproducible evidence trails.

What This Workflow Automates

1. Document ingestion and classification: The workflow accepts uploaded files of type MSA, SOW, Contract, Timesheet, Acceptance Record, and Offering, and assigns each to its correct document role in the contract hierarchy without manual tagging.
2. Contract and SOW extraction: Key terms are extracted from each MSA and SOW — parties, effective dates, total contract value, deliverable milestones, billing schedules, payment terms, and any variable consideration clauses (bonuses, penalties, success fees).
3. Performance obligation identification: The workflow parses each contract for distinct promises under ASC 606-10-25-19, flags bundled deliverables (e.g., a replatform plus a stand-ready support period), and records each as a separate performance obligation with its own recognition schedule.
4. Transaction price allocation: For multi-POB contracts, the workflow allocates the total contract price to each obligation using relative SSP, either from the Offering document (which records catalogue pricing) or from a controller-supplied SSP table, consistent with ASC 606-10-32-28 through 32-41.
5. Progress measurement and revenue scheduling: For each performance obligation, the workflow applies the elected measurement method — hours-based input method from timesheets for time-and-materials engagements, or milestone-based output method from acceptance records for fixed-fee deliverables — and computes the revenue recognized in each reporting period.
6. Variable consideration constraint enforcement: Bonus or contingent fee amounts are held as constrained variable consideration until a matching acceptance record is ingested; upon match, the constrained amount is released to recognized revenue in the period bearing the acceptance record's execution date, not the upload date.
7. Exception detection: The workflow deterministically flags four exception classes — (a) timesheet hours exceeding SOW fixed-fee estimates, triggering a loss-contract margin check under ASC 420; (b) contract modifications where added scope is priced at SSP, requiring treatment as a separate contract under ASC 606-10-25-12(a); (c) inconsistent progress measurement method changes from the elected method at contract inception; and (d) acceptance record execution dates that straddle a closed period, generating a prior-period adjustment memo.

All extraction, allocation, scheduling, and exception-flagging steps execute in under 90 seconds per contract batch, producing a structured, field-by-field output that any controller can trace back to the source document page and paragraph.

Edge Cases We Simulate

The workflow ships with a battery of synthetic test scenarios that exercise every failure mode we have seen in real-world data. Each scenario produces a deterministic outcome that an auditor or controller can verify in seconds.

Sample Documents

Download or inspect the seeded sample files used to demonstrate this workflow:

Sample Results

In the demo dataset, the workflow processed four documents covering a single client engagement: an MSA/SOW covering pages 1–8 and 9–16 of a website redesign and replatform agreement, a billable hours report for January through March 2026, and a client acceptance record. The contract contained two distinct performance obligations — the replatform deliverable and a post-launch support retainer — requiring independent transaction price allocation. The timesheet cross-reference identified that reported billable hours for Q1 2026 fell within the SOW estimate, confirming no loss-contract condition for the period. The acceptance record's execution date was read directly from the document's signature block, independent of its upload timestamp, ensuring revenue was posted to the correct reporting period.

Across the four reconciliation pairs in the demo run, the workflow matched each timesheet period to its originating SOW and each acceptance record to its corresponding SOW deliverable milestone. One specific exception class was exercised: the variable consideration constraint check confirmed that the performance bonus specified in the SOW was correctly held as constrained consideration at period-end, pending a formal client acceptance record. Until that document is ingested, the bonus amount does not flow into recognized revenue, preventing an upfront recognition error that would violate ASC 606-10-32-11.

Why Automation Wins Here

Replacing the manual ASC 606 close process with this workflow reduces the per-contract revenue close cycle from two to three days to under five minutes of controller review time. The four exception classes — loss contract, separate-contract modification, method inconsistency, and cut-off error — are caught deterministically on every run, eliminating the reliance on a reviewer's memory of which contracts have active bonuses or pending change orders. For a firm managing 60 active SOWs, that translates to roughly 120–180 hours of analyst time recovered per quarter, and a material reduction in the risk of a revenue restatement or audit adjustment.

Every output the workflow produces — the POB schedule, the SSP allocation table, the constrained variable consideration register, and any exception memos — is formatted as a stand-alone workpaper. Each field traces to a specific source document, page, and clause. The controller downloads the package directly into the audit file, where it satisfies the documentation standard under AICPA AU-C Section 230 (Audit Documentation) for revenue recognition evidence, without any reformatting or supplemental narrative required.

Frequently Asked Questions