How revenue recognition works for fixed-price projects

When you sell a fixed-price project, you know upfront how much you will invoice the client. But how much of that revenue have you earned at any given point during the project? That's the question revenue recognition answers.

This article explains why revenue recognition matters for consulting firms, how Operating's three methods work, and how to choose the right one for your projects.

Why fixed-price projects need revenue recognition

For time-and-materials projects, revenue recognition is straightforward: every tracked hour generates earned revenue at the applicable billing rate. The revenue is earned when the work is done.

Fixed-price projects are different. The total contract value (the budget) is agreed upfront, but the work is delivered over weeks or months. You need a method to determine how much of that budget value you've earned in any given period — especially when the project spans multiple financial reporting periods.

Without revenue recognition, your financials would show nothing earned until the final invoice, which doesn't reflect reality. Revenue recognition distributes the budget value across the project duration so that monthly reports, margin calculations, and planned vs. actuals comparisons are meaningful throughout the project's lifecycle.

The two revenue recognition methods

When you set a project's billing type to fixed-price, Operating asks you to choose a revenue recognition method. Each method determines how earned revenue is calculated for any given time period.

Based on time planned or tracked, weighed by hourly rates

This is the recommended method. It attributes revenue to the people doing the work, proportional to the value of their time.

How it works: Operating looks at the allocations (planned time) and time entries (tracked time) for the project. Each person's contribution is weighted by their applicable billing rate from the rate card. The total budget value is then distributed in proportion to these weighted contributions.

An example: A project has a budget of 100,000 EUR over five months. Two people work on it: a Senior Developer billed at 165 EUR/h and a Junior Developer at 110 EUR/h. If the Senior Developer has planned or tracked 200 hours and the Junior Developer 300 hours in a given period, the Senior's contribution is valued at 33,000 EUR (200 × 165) and the Junior's at 33,000 EUR (300 × 110). The earned revenue for that period is distributed proportionally based on these weighted values relative to the total weighted value across all periods.

Why it's recommended: This method gives you the most granular view because it can attribute revenue to specific people. This means per-person profitability reports are meaningful for fixed-price work, not just per-project ones. It also responds dynamically to how the project actually unfolds — if more senior people end up doing more work than planned, the revenue distribution adjusts accordingly.

When the plan and reality differ: This method uses time entries for past periods (what actually happened) and allocations for future periods (what's planned). This means the earned revenue calculation improves over time as plans are replaced by actuals. It's the same "projected values" principle described in Understanding planned vs. actuals.

Optional: Indicating budget progress when using the “based on time planned or tracked” method

You periodically enter a percentage indicating how much of the budget has been completed, and Operating calculates earned revenue from that.

How it works: In the project's financial setup, you set the budget progress as a percentage. If the budget is 100,000 EUR and you set progress to 60%, earned revenue is 60,000 EUR. You can update this as frequently as needed — some companies do it monthly as part of their month-end close routine.

An example: A project has a 200,000 EUR budget. After three months, the project owner estimates the work is about 45% complete. They set budget progress to 45%, and Operating records 90,000 EUR as earned revenue. A month later, they reassess and update to 62%.

When to use it: This is the right choice when the project owner or finance team wants to make a judgment call about completion that isn't directly tied to hours worked. It's common for projects where deliverables don't map neatly to time spent — for example, a strategy advisory engagement where a key milestone might represent 40% of the value even though it took only 20% of the total hours.

Limitation: It requires manual effort and discipline. If budget progress isn't updated regularly, earned revenue figures become stale and reports lose accuracy. The revenue logic basically falls back to the Based on time planned or tracked, weighed by hourly rates method.

Evenly by month or week

The simplest method. Revenue is distributed equally across every month in the budget's date range.

How it works: The budget value is divided by the number of months it covers. Each month earns an equal share.

An example: A 120,000 EUR budget covering January through June (6 months) earns 20,000 EUR per month, regardless of how many hours were tracked or how the team was staffed.

When to use it: This works well for retainer-style engagements or projects where the work is expected to be roughly uniform month to month. It's also useful when you don't need person-level revenue attribution and want a predictable, easy-to-explain number.

Limitation: It doesn't reflect actual delivery pace. If the project is front-loaded or back-loaded, the earned revenue won't match reality until the project completes.

How budgets interact with revenue recognition

A fixed-price project must have at least one budget for revenue recognition to work. The budget defines the total value that the revenue recognition method distributes.

Single budget

Most fixed-price projects have one budget covering the entire engagement. The revenue recognition method applies to this budget over its full date range.

Multiple budgets

Projects with distinct phases or contract amendments can have multiple budgets, each with its own date range and value. Budgets may not overlap in time. Revenue recognition applies independently to each budget within its date range.

For example, a project might have a Phase 1 budget of 120,000 EUR (April–August) and a Phase 2 budget of 80,000 EUR (September–December). The chosen revenue recognition method distributes each budget's value separately within its respective period.

Work outside of budget periods earns zero revenue

Revenue recognition only applies within the date range of a budget. If a person tracks time on a fixed-price project during a period that falls outside any budget's date range, that work will show zero earned revenue — even though it incurs costs.

This matters in practice. If the team starts work before the budget period begins, or continues working after the budget period ends, those hours will show up with costs but no revenue. The project's margin will look worse than expected because those hours are essentially "free" from a revenue recognition perspective.

To avoid this, make sure your budget dates cover the full period during which work is expected. If the project timeline extends beyond the original plan, either extend the existing budget's end date or add a new budget for the additional period.

Past budgets are automatically considered fully earned

When a budget's end date has passed, Operating treats it as 100% complete. All of the budget's value is counted as earned revenue, regardless of whether you've set the budget progress to 100%.

This means you don't need to go back and manually set progress to 100% on completed budget periods. Once the end date passes, the full budget value is earned. This is true for all revenue recognition methods.

Choosing the right method

If you're unsure, start with weighted by hours and rates. It requires no manual input beyond normal allocation and time tracking, it gives you person-level detail, and it adapts to how the project actually unfolds.

How revenue recognition affects reports

The method you choose directly impacts several parts of Operating:

Earned revenue — the "actual" side of planned vs. actuals for revenue. Each method calculates this differently, so switching methods mid-project will change how past earned revenue is reported.

Gross profit and margin — since these are derived from earned revenue minus tracked costs, the revenue recognition method affects your profitability picture.

Projected values — Operating's projections for fixed-price projects use the revenue recognition method to estimate remaining revenue. The "weighted by hours/rates" method is most responsive here, since it factors in actual team composition.

Invoicing — revenue recognition is independent of invoicing. You might recognize 50,000 EUR in earned revenue for a month but not invoice the client until the next month, or invoice a different amount. Earned revenue and invoiced revenue often differ, and that's normal. See the glossary definitions of earned revenue and invoice for more on this distinction.

Practical guidance

Don't change methods mid-project. Switching revenue recognition methods recalculates earned revenue for all periods, which can create confusing jumps in financial reports. Pick a method at the start and stick with it.

If using budget progress, build it into your routine. The most common cadence is monthly, aligned with your month-end close process. Some firms add "update budget progress on all active fixed-price projects" as a step in their close checklist.

Revenue recognition is about earned revenue, not cash. A common source of confusion: revenue recognition doesn't determine when you invoice or when you get paid. It determines when the revenue is recorded in Operating's financial reports. The invoicing schedule is configured separately and controls when invoices are created.

Related articles

• Understanding planned vs. actuals — how planned and earned revenue are compared

• Set up: Financials — configuring billing types, budgets, and rate cards

• Set up: Rate cards — billing rates that drive the "weighted by hours/rates" method

• Project budgeting & profitability — managing budgets and tracking financial performance