From Contract to Revenue: Where ASC 606 Breaks Down

From Contract to Revenue: Where ASC 606 Breaks Down

Your contract says $360,000. Your CRM says $320,000. Your billing system says $340,000. Your RevRec system picked one of them. Which one? You'll find out at audit.

Each handoff introduces errors that compound, making revenue unauditable by the time finance closes the books.

This article traces the path a SaaS contract takes from execution to recognized revenue. At each stage: what's supposed to happen, what actually happens, and where to establish controls before errors compound.

Stage 1: Contract Negotiation and Execution

Ambiguous contract terms are the first point of ASC 606 failure, if the signed document doesn't capture what was actually promised, compliant revenue recognition becomes impossible downstream.

What's supposed to happen:

Sales and legal finalize terms. The signed contract establishes transaction price, defines deliverables, specifies payment terms, and documents non-standard provisions. This document becomes the source of truth for everything downstream.

What actually happens:

By the time a deal closes, terms have been negotiated across email threads, revised in redlines, and finalized in a PDF that may not reflect the last conversation. Verbal commitments never appear in the final document. Side letters get executed separately. Discount structures described in proposals aren't fully documented.

Controllers and revenue accountants rarely see contracts at this stage. By the time the deal reaches booking, the nuance is already lost.

Where ASC 606 breaks:

Step 1 of ASC 606 requires identifying the contract. Step 2 requires identifying performance obligations. Both depend on understanding what was actually promised. If the signed document is ambiguous or contradicted by side agreements, the foundation for compliant recognition is already compromised.

Control point: Establish deal desk review for non-standard terms before execution. Flag contracts with implementation services, usage components, or custom SLAs for finance visibility.

Stage 2: Booking

Booking is the single largest source of downstream revenue data errors, wrong TCV, wrong term lengths, and discount misfields become the foundation for every system that follows.

What's supposed to happen:

Sales marks the deal closed in the CRM. Opportunity fields capture essential contract data: TCV, term length, start date, products sold, billing frequency, discounts. This data feeds downstream systems.

What actually happens:

CRM data entry is a tax on salespeople. They're incentivized to close deals, not ensure field-level accuracy for finance processes they don't see.

TCV gets entered as ACV. Start dates default to close date rather than service commencement. Multi-year deals get booked with wrong term lengths. Discount percentages land in the wrong field. Validation rules catch obvious errors but can't detect that the $180,000 in Salesforce should be $216,000 based on the contract's escalation clause.

Where ASC 606 breaks:

Every downstream system inherits booking data. If TCV is wrong here, it's wrong in billing, wrong in RevRec, and wrong in your revenue waterfall. By month six of a three-year contract, cumulative recognition variance can be material. Finance teams managing Salesforce order reconciliation see this pattern repeatedly.

Control point: Implement booking reconciliation that compares CRM data to contract documents before deals flow downstream. Catching errors here costs minutes. Catching them at close costs days.

Stage 3: Billing Setup

Billing setup errors create a permanent gap between what the contract says and what finance systems believe, a gap that compounds every billing cycle until audit.

What's supposed to happen:

Finance or billing operations creates the invoicing schedule based on contract terms. The billing system receives customer data, pricing, and schedule parameters. Invoices generate automatically.

What actually happens:

Billing setup is a re-entry exercise. A billing operations analyst reads the CRM record (or the contract, if they're thorough) and manually configures the billing system.

Billing schedules don't match contract terms. First-year discounts get applied to all years, or not at all. Usage components get configured with wrong thresholds. Service start dates diverge from CRM. The billing system and CRM have different data models, so a "3-year deal" in Salesforce might become three separate annual subscriptions in billing. These translations are rarely validated.

Where ASC 606 breaks:

Step 3 requires determining the transaction price. If billing is configured incorrectly, transaction price in your revenue system won't match the contract. You'll recognize revenue you shouldn't, or fail to recognize revenue you should.

Control point: Build billing-to-booking reconciliation that runs before invoices generate. Compare TCV, term, and schedule between CRM and billing. Variances require explanation before proceeding. This is where revenue assurance practices become critical, establishing controls that catch discrepancies before they cascade downstream.

Stage 4: Service Delivery

Service delivery timing mismatches cause ASC 606 failures because finance recognizes revenue before control transfers, they simply have no visibility into actual provisioning dates.

What's supposed to happen:

The customer receives what they paid for. Platform access gets provisioned. Implementation milestones get completed. Training sessions get delivered. Each performance obligation is satisfied according to the contract.

What actually happens:

Delivery tracking lives in systems that don't talk to finance. Customer success manages onboarding in their platform. Professional services tracks projects in their tool. Controllers have no systematic visibility into whether performance obligations are actually being satisfied.

Here's a concrete example: A customer signs a $120,000 annual subscription on January 1. Due to SSO integration delays, provisioning doesn't complete until February 15. The billing system doesn't know about the delay. Neither does RevRec. Finance recognizes $10,000 in January and $10,000 in February based on the contract start date. But under ASC 606, control hadn't transferred in January. That $10,000 is non-compliant. Auditors flag it nine months later.

Where ASC 606 breaks:

Step 5 requires recognizing revenue when performance obligations are satisfied. Without delivery data connected to contract and billing data, finance assumes delivery matches contract terms because they have no evidence otherwise. That assumption fails audit.

Control point: Integrate provisioning and delivery data into your revenue process. Validate that service start dates in the revenue system match actual provisioning dates. For professional services, ensure project completion triggers recognition rather than arbitrary schedules.

Stage 5: Revenue Recognition

RevRec systems process bad inputs with perfect accuracy, producing compliant-looking schedules built on foundations that crumbled four stages earlier.

What's supposed to happen:

The RevRec system ingests contract data, applies accounting policies, and generates recognition schedules. SSP allocation happens for bundled arrangements. Schedules post to the subledger. Journal entries flow to the GL.

What actually happens:

RevRec systems are only as good as their inputs. By Stage 5, data has degraded through four prior handoffs. The RevRec system faithfully applies your policies to whatever it receives.

Contract data in RevRec doesn't match source systems. Modifications get handled inconsistently. SSP tables are outdated. Manual overrides from prior periods have no documentation. Revenue recognition automation vendors assume you've solved the data integrity problem upstream. Most companies haven't.

Where ASC 606 breaks:

If RevRec shows $1.2M recognized for a customer but contract, billing, and delivery data support $1.35M, no amount of accounting sophistication will fix it. The error is in the inputs.

Control point: Run monthly reconciliation between source systems and RevRec. Compare contract samples across CRM, billing, and RevRec. Variances reveal upstream breaks. This is the core of revenue integrity: ensuring recognized revenue traces cleanly to its source.

Stage 6: Close and Audit

Audit doesn't just test whether your accounting is correct, it tests whether you can prove it's correct. If tracing revenue to its source requires tribal knowledge and spreadsheet forensics, you have an evidence problem.

What's supposed to happen:

Finance closes the books. Auditors review transaction samples, test controls, and verify recognition aligns with ASC 606. Everyone agrees the numbers are right.

What actually happens:

Close is a reconciliation scramble. Finance discovers variances that should have surfaced earlier. Audit asks for contract support that takes hours to locate. Explanations require tracing data across five systems manually.

Deferred revenue includes amounts that can't be tied to active contracts. Revenue waterfall shows unexplainable movements. Prior period adjustments are required because errors weren't caught earlier. Companies with weak order to cash reconciliation processes face the most painful audits.

Where ASC 606 breaks:

Auditors don't just test whether your accounting is correct. They test whether you can demonstrate it's correct. If tracing a revenue line item to its source contract requires tribal knowledge, email searches, and spreadsheet forensics, you have an evidence problem even if the accounting is fine.

Control point: Build audit trails at each prior stage, not at close. Every data transformation, manual entry, and override should be logged with timestamp, user, and justification.

The Compounding Cost of Late Detection

A booking error caught at Stage 2 takes minutes to fix. The same error caught at Stage 6 requires weeks of forensic reconstruction and risks material weakness findings. Every stage of delay roughly 10x the remediation cost.

Most finance teams invest heavily in Stage 5 (RevRec software) and Stage 6 (close processes). Far fewer invest in Stages 1 through 4, where errors originate.

Key Takeaways

ASC 606 compliance doesn't break in the RevRec system, it breaks upstream. The six-stage contract-to-revenue journey introduces data degradation at every handoff:

• Contract execution: Ambiguous terms and undocumented side agreements compromise the foundation for compliant recognition
• Booking: CRM data entry errors become the inherited truth for every downstream system
• Billing setup: Manual re-entry creates permanent gaps between contract terms and system data
• Service delivery: Finance recognizes revenue without visibility into actual provisioning timing
• Revenue recognition: RevRec systems process bad inputs accurately, producing compliant-looking schedules on flawed foundations
• Close and audit: Evidence problems surface months after errors originated

The ROI math is simple: Catching a $10,000 TCV error at booking takes five minutes. Catching it at audit takes a week. Invest in Stages 1–4, not just 5–6.

Frequently Asked Questions

Where do most ASC 606 compliance errors originate?

Most ASC 606 compliance errors originate in three operational stages: contract execution (ambiguous terms and undocumented commitments), booking (CRM data entry errors), and billing setup (manual re-entry mistakes). These are operational stages managed by sales, deal desk, and billing teams who aren't thinking about revenue recognition. By the time data reaches finance systems, errors are already baked in. The RevRec system processes bad inputs accurately, producing compliant-looking schedules built on flawed foundations.

How do I trace recognized revenue back to the source contract?

Start with the customer or contract ID in your revenue system. Cross-reference to billing to verify invoice schedules match recognition schedules. Cross-reference to CRM to verify booking data matches billing. Locate the signed contract to verify CRM data matches agreed terms. If any link breaks, you've found the gap. This traceability should be automated and continuous rather than manual and periodic.

Why does my RevRec system show different values than my CRM?

RevRec systems and CRMs have different data models and often receive data through different paths. Differences emerge from integration mapping errors, timing of data sync, manual adjustments in one system but not the other, or modification handling that updates one system but not both. Reconciliation between these systems should happen monthly at minimum.

How do contract modifications affect ASC 606 compliance?

ASC 606 provides three treatments depending on the nature of the change. If the modification adds distinct goods at standalone selling price, treat it as a separate contract. If it adds distinct goods but not at standalone selling price, terminate the old contract and create a new one prospectively. If it doesn't add distinct goods, combine with the original and adjust cumulatively. The operational challenge is tracking modifications consistently and having enough data to determine which treatment applies.

What's the difference between a billing error and a revenue recognition error?

A billing error means the customer receives an invoice that doesn't match contract terms. A revenue recognition error means the amount or timing of recognized revenue doesn't comply with ASC 606, regardless of what was billed. You can bill correctly and recognize incorrectly, or vice versa. Both could be consistently wrong relative to the source contract.

How often should I reconcile contract data across systems?

Monthly is the minimum for reconciliation between CRM, billing, and RevRec. High-volume SaaS companies with frequent modifications should consider continuous reconciliation that flags variances in real-time. The goal is catching errors before close, not during it.

What does ASC 606 require for audit evidence?

ASC 606 audit evidence requires demonstrating that recognition timing and amounts align with the five-step model. For each sampled transaction, produce the contract, show how you identified performance obligations, document SSP methodology and allocation, and trace recognition to delivery. If this evidence requires manual assembly across disconnected systems, audit will be painful and risky.

Safebooks provides continuous reconciliation across CRM, billing, and ERP systems, giving finance teams visibility into contract data integrity at every stage from booking to recognized revenue.