Revenue Recognition Is Not a Spreadsheet Problem

ASC 606 compliance lives in spreadsheets at most mid-market companies. The ERP records the invoice. The spreadsheet figures out when it’s actually revenue. This arrangement works until a contract gets amended, a subscription changes mid-term, or an auditor asks to see the supporting workpapers for every deferred revenue balance. At that point, the spreadsheet becomes the problem.

Revenue recognition under ASC 606 is a five-step model. Identify the contract. Identify the performance obligations. Determine the transaction price. Allocate the price to the obligations. Recognize revenue when each obligation is satisfied.¹ Stated at that level of abstraction, the model sounds manageable. In practice, the complexity compounds rapidly with every variation in contract structure.

A SaaS company selling a platform subscription with an onboarding fee and a professional services component has at least three performance obligations in a single contract. The transaction price needs to be allocated across those three obligations based on their standalone selling prices. Revenue recognizes differently for each: the platform subscription ratably over the contract term, the onboarding at the point in time when onboarding is complete, the professional services as the project progresses. If the customer upgrades mid-term, the contract modification rules determine whether this is a new contract, a modification of the existing one, or both.

Where the spreadsheet comes from

Most mid-market ERP systems, including NetSuite, record the invoice at the time it’s generated. Some have native revenue recognition modules that can automate ratable recognition over a contract term. Very few can natively handle the full complexity of multi-element arrangements, contract modifications, variable consideration, and the allocation methodologies required by ASC 606.

The spreadsheet fills the gap. The controller builds a model that takes the contract data, identifies the performance obligations, allocates the transaction price, and generates the period-by-period recognition schedule. The model then produces the deferred revenue balances and the revenue entries for each period, which get posted manually to the ERP.

This arrangement is technically compliant — the accounting is being done correctly, just in a spreadsheet rather than in the system. The problems appear when: (1) a contract changes and the spreadsheet model needs to be updated retroactively, (2) the volume of contracts exceeds what one controller can manage in a spreadsheet without error, (3) the controller leaves, (4) the auditors ask to trace every deferred revenue balance back to a contract and the workpapers are organized by the way the model happened to be built.²

The systematic alternative

Revenue recognition belongs in the same system that records the contract and generates the invoice — not because of convenience, but because the recognition schedule is derived from the contract terms, and the contract terms live in the system. If the system knows the contract start date, end date, performance obligations, and allocation methodology, it can generate the recognition schedule automatically. When the contract changes, the recognition schedule updates accordingly. The deferred revenue balance is a live calculation, not a monthly manual entry.

This requires the system to have a contract model sophisticated enough to capture the relevant terms — not just “start date and end date” but the full obligation structure. It requires the recognition logic to be rules-based and configurable for different obligation types. And it requires those rules to be enforced consistently, without manual intervention that can introduce error.

The audit evidence produced by this model is also stronger. The deferred revenue balance is traceable to specific contract line items in the system. The recognition entries are generated automatically from those line items. The workpapers for an auditor are the system records, not a spreadsheet maintained by one person.

The practical gap in the market

Revenue recognition is an area where the ERP market has consistently underserved mid-market companies. Enterprise systems like SAP have sophisticated recognition modules designed for exactly this complexity. Mid-market systems often have basic ratable recognition and leave the more complex scenarios to the spreadsheet. The consequence is that mid-market companies with complex revenue models — SaaS, professional services, subscription + services bundles — end up maintaining parallel systems: the ERP for invoicing and the GL, the spreadsheet for recognition.

This is a solvable problem at the architecture level. It requires treating the contract as the source of financial truth, not just a document that generates invoices.

Sources