How should a professional services automation tool handle revenue recognition?

A good professional services automation tool recognizes revenue automatically from the project data you already keep, across every contract type you sell, and lets you both forecast and report recognized revenue from one model. If you're evaluating tools, that's the bar. Below is a checklist of buying questions to judge any professional services automation tool against, followed by how Operating handles each one.

Professional services automation (PSA) software is the system a services firm uses to run projects, staffing, time, and financials in one place. Revenue recognition is one of the harder things it has to get right, and not every tool does. Under ASC 606, professional services firms recognize revenue as they deliver work rather than when they invoice, following a five-step model that ties revenue to performance obligations and progress toward completion.

Why accounting software alone falls short

Accounting and ERP systems like Oracle NetSuite and Microsoft Dynamics 365 Business Central handle financial reporting well, but they usually lack the operational data that services revenue recognition depends on. Recognition in a services firm runs on time entries, staffing plans, resource allocation, cost rates, and project budgets, and that data lives in your delivery and resource-planning systems, not your general ledger.

When finance tries to do recognition in the accounting system alone, the gap gets filled with spreadsheet exports, manual reconciliation, and numbers that land days after the period they describe. The calculations are not the problem. The friction is operational: pulling time, cost, and staffing data into the accounting system by hand, after the work has already happened. This is the same split we wrote about in why consulting firms keep falling back to spreadsheets despite their ERP: keep finance in the ERP, and run the operational data, including recognition, where it actually lives. If you're weighing up where that operational layer should sit, we also compared the options in our guide to NetSuite OpenAir alternatives for professional services.

The revenue recognition checklist for a PSA tool

Use these as vendor-neutral questions when you evaluate any professional services automation tool.

1. Does it support every contract type you actually sell? Time and materials, fixed price, capped or not-to-exceed, and non-billable work should all be first-class. A tool that only handles time and materials cleanly will push your fixed-price work back into a spreadsheet.

2. Does it offer more than one way to recognize fixed-price work? Even spread across the project, weighted by effort and value, and cost-based progress are all valid, depending on the engagement. One rigid method won't fit every fixed-price deal you sign.

3. Does recognition run off real project data? Recognition should be driven by your actual time, cost, and budgets, from one source of truth, not a parallel schedule someone maintains by hand.

4. Does it keep recognized revenue separate from invoiced revenue? You need to see earned-but-unbilled and billed-ahead amounts distinctly, or your revenue and your invoicing will quietly disagree.

5. Does it forecast recognized revenue from the resource plan, then reconcile to actuals? Reporting after close is table stakes. Projecting recognized revenue from who is staffed where is what lets you see the quarter coming.

6. Can you override the formula when reality doesn't fit it? Real projects go sideways. The tool should let you correct recognition manually when the automated method is wrong. The tool should allow recognizing negative revenue.

7. Does it handle open, unfinished periods without over-recognizing? A fixed-price budget that isn't finished shouldn't have its full value recognized early just because a date has passed.

How Operating handles revenue recognition

Operating is a professional services automation platform built for consulting firms, agencies, and other services businesses. It's the operational system of record for a services firm, designed to keep your own finance stack: Operating produces the recognition numbers from delivery data and hands them to the accounting system you already run, rather than replacing it. Here is how it answers each question above.

Every contract type

Operating supports fixed price, time and materials, capped time and materials, and non-billable work as native contract types. You don't model a fixed-price project as a workaround on top of time and materials. Each type behaves the way it should, for both billing and recognition.

Multiple recognition methods for fixed-price work

Operating recognizes fixed-price revenue four ways: evenly by week, evenly by month, weighted by hours and rates, and cost-to-cost (recognizing revenue in step with actual cost against planned cost). You pick the method that matches the engagement instead of forcing every fixed-price deal through one formula.

One model for planned and actual

Operating runs forecast and actuals from the same model. It forecasts recognized revenue from your allocations (who is planned on which project), and actuals come from time entries and expenses. The plan and the result live in one place, so reconciling them is a comparison, not a reconstruction.

Recognized is tracked apart from invoiced

Operating tracks recognized revenue and invoiced revenue separately, so you can see earned-but-not-yet-billed revenue at any point. The recognition number reflects delivery, the invoicing number reflects billing, and the gap between them is visible instead of hidden.

Manual progress for messy timelines

Operating lets you enter budget progress manually when work doesn't line up neatly with budget dates. If a fixed-price engagement's real progress doesn't match its planned schedule, you can record where it actually stands and recognize against that, rather than against a calendar.

Open periods handled correctly

Operating doesn't over-recognize unfinished fixed-price budgets. An open budget that isn't complete is recognized for what's been delivered, not its full value, so a passing date never inflates the period.

What this gives a finance leader

For a CFO or finance lead at a services firm, getting recognition right in a professional services automation tool buys a few concrete things:

• Audit-readiness, because recognition is tied to traceable project data rather than a hand-built spreadsheet.
• More accurate forecasts, because recognized revenue is projected from the resource plan, not guessed at quarter-end.
• Fewer month-end spreadsheets, because the recognition runs from data that's already in the system.
• Finance and delivery working from the same numbers, because both read from one model instead of two.

The payoff is easiest to see on a project that's going wrong. Take a $120,000 fixed-price engagement. If the team logs far more hours than planned, cost climbs while the contract value stays put, and the margin erodes. When recognition runs off the same data as your time and cost tracking, that erosion shows up during the project rather than at year-end close, while you can still reprice, re-staff, or have the conversation with the client.

For more on the category itself, we wrote a full explainer on professional services automation software, and a deeper piece on revenue recognition in professional services.

See it on your own contract types

The fastest way to judge a professional services automation tool on revenue recognition is to run it against the contracts you actually sell. Book a demo and we'll set up recognition on your contract types so you can see how the numbers come out.

Frequently asked questions

How does a PSA tool handle revenue recognition?

A professional services automation (PSA) tool recognizes revenue automatically from a firm's project data: time, cost, and budgets. It applies the right method per contract type, keeps recognized revenue separate from invoiced revenue, and ideally forecasts recognized revenue from the resource plan as well as reporting it after the period closes.

What recognition methods should a PSA tool support for fixed-price work?

A PSA tool should offer more than one method for fixed-price recognition, because no single formula fits every engagement. Operating, for example, recognizes fixed-price revenue evenly by week, evenly by month, weighted by hours and rates, or cost-to-cost (in step with actual versus planned cost).

What contract types does Operating support for revenue recognition?

Operating supports fixed price, time and materials, capped time and materials, and non-billable work as native contract types. Each is recognized the way it should be, so fixed-price projects don't have to be modeled as a workaround on top of time and materials.

Can a PSA tool forecast revenue, not just report it?

Yes. A PSA tool like Operating forecasts recognized revenue from the resource plan, the allocations showing who is staffed on which project, and then reconciles that forecast to actuals from time entries and expenses. This lets finance see the quarter's revenue coming rather than learning it at close.