Revenue recognition compliance for professional services firms is operationally complex in a way that most accounting software was not designed to handle. ASC 606 and IFRS 15 require firms to recognize revenue as performance obligations are satisfied — which means the timing of revenue recognition is tied to project delivery events, not to cash receipts or invoice dates. In a firm running dozens of simultaneous engagements across T&M, fixed-fee, milestone, retainer, and hybrid contract structures, manually tracking performance obligation completion and producing the correct recognized revenue entries each period is a significant accounting burden. Enterprise PSA software addresses this by embedding the revenue recognition logic directly into the delivery data model — connecting time entry, milestone completion, and contract structure to the GL entries the ERP needs to close the period correctly.
Why Revenue Recognition Is Operationally Complex for Services Firms
The complexity in services revenue recognition is not primarily a technical accounting problem — most CFOs and controllers understand the standards. It is a data problem. To recognize revenue correctly under ASC 606, finance needs to know, for every engagement and every period: what was promised to the client (the performance obligation), what has been delivered so far (satisfaction of that obligation), and what the standalone selling price of each deliverable was at contract inception. In a firm where projects run for months, scope changes, and the same client may have multiple overlapping engagements with different contract structures, assembling this information manually from time entries, project status reports, and contract documents takes significant effort and introduces significant risk of error.
Enterprise PSA software reduces that effort by maintaining the connection between the contract structure and the delivery data in a single system. The contract terms — which define the performance obligations — are configured in the PSA at engagement setup. The delivery data — time entries, expense records, milestone achievements, percent complete estimates — is captured in the PSA as the project runs. The PSA can therefore produce a recognized revenue calculation for each engagement each period that reflects both the obligation structure and the actual delivery progress, without requiring finance to reassemble that connection manually.
The Five-Step ASC 606 Model in a PSA Context
ASC 606 structures revenue recognition around five steps: identify the contract, identify the performance obligations, determine the transaction price, allocate the transaction price to the obligations, and recognize revenue as each obligation is satisfied. Enterprise PSA supports this model at the operational level — not as a theoretical framework but as a set of configurations that produce compliant revenue entries.
Step one and two — identifying the contract and its performance obligations — happen at engagement setup. The contract line items configured in the PSA correspond directly to performance obligations: a fixed-fee implementation phase is one obligation, a recurring support retainer is another, a T&M advisory arrangement is a third. Each is modeled separately, with its own transaction price and its own recognition method.
Steps three and four — determining and allocating the transaction price — require judgment that the PSA supports but does not make autonomously. When a contract contains both a fixed-fee implementation and a recurring support element, the standalone selling prices of each must be established and the bundled transaction price allocated between them. The PSA holds the resulting allocation as part of the contract structure. Finance documents the allocation methodology externally, and the PSA enforces it consistently across every revenue recognition period without requiring finance to re-perform the calculation.
Step five — recognizing revenue as obligations are satisfied — is where the PSA’s delivery data does the most work. For T&M obligations, satisfaction occurs as hours are delivered; revenue recognized equals hours times billing rate for the period. For fixed-fee obligations, satisfaction is measured by percent complete or milestone achievement, and the PSA applies the recognition method configured at setup to the delivery data it holds.
How Contract Type Determines the Recognition Method
The contract type configured for each engagement line item determines how the PSA produces its recognized revenue calculation. Enterprise PSA platforms support multiple recognition methods that correspond to the ASC 606 output method and input method approaches.
- T&M and not-to-exceed contracts: revenue recognized in the period equals approved time and expenses multiplied by the applicable billing rates. Recognition is contemporaneous with delivery — hours logged, approved, and within contract terms in the current period generate recognized revenue for that period. This is the simplest recognition method and the most directly tied to the PSA’s time entry data.
- Fixed-price, percent complete: recognized revenue each period equals the contract value multiplied by the percentage of the work completed as of period end. The PSA uses budget versus actuals data (hours consumed relative to total estimated hours, or costs incurred relative to total estimated costs) to calculate the percent complete figure. Finance reviews and confirms the percent complete estimate before the period-end GL entry is generated.
- Fixed-price, revenue schedule: recognized revenue follows a predetermined schedule — a fixed amount per period, or amounts tied to specific milestones regardless of delivery progress. The schedule is configured at contract inception and followed mechanically, with the PSA producing the correct recognized amount each period based on the schedule rather than actual delivery data.
- Service contracts with overages: a base amount of hours is contracted at a fixed price (recognized ratably over the service period), and hours above the contracted ceiling are billed at a T&M rate (recognized as delivered). The PSA models both the base contract and the overage tracking within the same engagement structure.
WIP Management and Period-End Compliance
Work in progress balance management is the operational mechanism that makes period-end revenue recognition tractable at scale. WIP represents work that has been delivered but not yet invoiced — or work that has been invoiced but not yet earned. Both create recognized revenue adjustments that need to flow through the GL at period end.
Enterprise PSA tracks WIP at the engagement level in real time: as time is approved and billing periods close, the PSA calculates the WIP balance for each engagement — the difference between what has been delivered, what has been invoiced, and what has been recognized. At period end, finance reviews the WIP positions across all active engagements, confirms the recognition calculations, and the PSA produces the GL journal entries — recognized revenue credits and WIP debit/credit adjustments — that the ERP needs to close the period. The alternative — finance manually calculating WIP for each of dozens of engagements from project status reports and contract documents — is the process that enterprise PSA replaces.
Example: A 240-person management consulting firm closes its Q3 books with 38 active engagements across T&M, fixed-fee, and retainer contract structures. For each engagement, the PSA calculates the recognized revenue for the quarter based on the contract type and delivery data: T&M hours approved, percent complete estimates for fixed-fee projects reviewed by project managers, and scheduled amounts for retainers. Finance reviews the recognized revenue report, adjusts three percent complete estimates where the project manager’s assessment differs from the input method calculation, and approves the period-end WIP entries. The PSA generates the GL journal entries for all 38 engagements and sends them to the ERP for posting. Total finance time for the revenue recognition close: four hours, down from the two days it required before the PSA was implemented.
Where the PSA Ends and the ERP Begins in the Recognition Chain
The division of responsibility between the PSA and the ERP in revenue recognition compliance is important to understand because it determines where the accounting controls sit. The PSA is not the system of record for recognized revenue — the ERP is. The PSA’s role is to produce recognition-ready data: the calculation of how much revenue should be recognized for each engagement each period, based on the contract structure and the delivery data it holds. The ERP’s role is to receive that data, apply any entity-level adjustments the accounting team requires, and post the recognized revenue to the appropriate GL accounts with the correct period date.
This division means that the revenue recognition compliance controls span both systems. The PSA controls the accuracy of the delivery data (time entry approval workflows, WIP balance calculations, percent complete estimates) and the contract structure (correct CLI configuration, standalone selling price allocation). The ERP controls the GL posting (correct account mapping, correct period, correct entity) and the financial statement output. Auditors reviewing revenue recognition compliance will examine both systems — the PSA’s contract and delivery records as evidence of performance obligation satisfaction, and the ERP’s GL entries as evidence of the accounting result.
Mixed-Contract Engagements and the Allocation Challenge
The most operationally demanding revenue recognition scenarios in professional services involve engagements where multiple contract types apply simultaneously — a fixed-fee implementation phase delivered concurrently with a T&M advisory arrangement for the same client under the same master agreement. Under ASC 606, these need to be identified as separate performance obligations with separately allocated transaction prices, even if they are invoiced together or managed as a single engagement from the client relationship perspective.
Enterprise PSA handles this through the contract line item model: each obligation within an engagement is configured as a separate CLI with its own contract type and recognition method. The fixed-fee phase generates recognition based on percent complete. The T&M phase generates recognition based on approved hours. The two streams are calculated independently and aggregated at the engagement level for reporting purposes, while remaining separately auditable at the CLI level. Finance can produce a recognized revenue breakdown by obligation for any engagement — which is the evidence structure that auditors request when reviewing multi-element arrangement accounting under ASC 606.
Questions to Ask During PSA Evaluation
Three questions differentiate PSA platforms with genuine ASC 606 support from those where recognition is a reporting feature rather than an operational one.
First: show us how the platform handles a fixed-fee engagement where the percent complete estimate is revised mid-project due to scope change. Specifically, what happens to the cumulative recognized revenue when the estimate changes, and how does the catch-up adjustment appear in the period-end GL entry? This tests whether the platform applies the ASC 606 cumulative catch-up method correctly or simply recognizes the current period’s incremental amount without adjusting for prior period over- or under-recognition.
Second: show us a multi-element engagement with a fixed-fee phase and a T&M retainer configured as separate CLIs. Produce the period-end recognized revenue for both obligations from the same engagement record. This tests whether the CLI-level multi-method recognition model actually works in a production scenario or whether it requires manual separation at the end of each period.
Third: how does the platform handle a change to the contract terms after project start — for example, a modification that adds a new deliverable and adjusts the transaction price? Does the platform support the modification accounting approaches in ASC 606 (separate contract, cumulative catch-up, or prospective treatment) or does it require the accounting team to handle all modifications manually outside the system? The answer reveals the depth of the ASC 606 implementation — modifications are where most PSA platforms’ compliance support runs out.
