> For the complete documentation index, see [llms.txt](https://help.modelreef.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.modelreef.io/use-cases/professional-services-and-consulting/rate-card-and-billable-hours-forecasting.md).

# Rate Card & Billable Hours Forecasting

This use case explains how to build a rate card and billable hours forecasting engine for professional services and consulting firms in Model Reef.

You will:

* Define rate cards by role, grade, office or practice.
* Forecast billable hours per role and location.
* Use those hours and rates to drive revenue.
* Integrate the result with utilisation and capacity planning, and with project pipeline schedules.

## When to use this pattern

Use this pattern when:

* Your revenue is driven by billable time and rates.
* You need to test changes in rates, discounting or mix.
* You want revenue forecasts to derive from headcount, utilisation and rate cards rather than top down assumptions.

It pairs naturally with:

* **Utilisation and Capacity Planning**
* **Project Pipeline and Revenue Scheduling**
* **Office or Team Profitability Modelling**

## Architecture overview

You will build three main elements:

* Rate card drivers
  * Rates per role, grade, office or service line.
  * Optional different rates per client type or channel.
* Billable hours drivers and variables
  * Billable hours based on FTE, utilisation and realisation.
  * Optional adjustments from project pipeline schedules.
* Revenue variables and outputs
  * Revenue per role and branch.
  * Aggregated firm revenue and margin.

{% stepper %}
{% step %}

### Decide rate card dimensions

First decide how granular your rate card needs to be, for example:

* Role based only:
  * Consultant, Senior Consultant, Manager, Director, Partner.
* Role and office:
  * Consultant - London vs Consultant - Manchester.
* Role and service line:
  * Strategy Consultant vs Technology Consultant.

More granular rate cards give more detail but require more maintenance. Choose the smallest set of dimensions that meaningfully affect pricing decisions.
{% endstep %}

{% step %}

### Create rate card drivers

In the Data Library, create drivers for rates, for example:

* `Rate - Consultant - London`.
* `Rate - Senior Consultant - London`.
* `Rate - Manager - London`.
* `Rate - Consultant - Manchester`.

These should be periodic series so you can represent planned rate increases over time, for example:

* Annual increases each financial year.
* Step changes to reflect a strategic shift in pricing.

You can use manual, regression or ML based presets if you want rate changes to follow a pattern, but in many cases manual edits are sufficient.
{% endstep %}

{% step %}

### Build billable hours from capacity and utilisation

Reuse or create drivers for:

* FTE per role and branch.
* Available hours per FTE.
* Utilisation percentages.
* Realisation percentages.

Then, in each branch, define variables such as:

* `Available Hours - Consultant - London`.
* `Billable Hours - Consultant - London`.
* `Realised Billable Hours - Consultant - London`.

For example:

* Available hours = FTE × available hours per FTE.
* Billable hours = available hours × utilisation.
* Realised billable hours = billable hours × realisation.

These variables can either be stand alone or integrated directly into the utilisation and capacity structure.
{% endstep %}

{% step %}

### Create revenue variables per role and branch

For each role and branch, define Revenue variables such as:

* `Revenue - Consultant - London`.
* `Revenue - Senior Consultant - London`.
* `Revenue - Manager - Manchester`.

Set the formula to:

* Revenue = realised billable hours × relevant rate driver.

Ensure these variables are typed as **Revenue** so they feed P\&L, Cashflow and Cash Waterfall.

You may also add summarising revenue variables by practice, office or service line that sum multiple role level variables for reporting.
{% endstep %}

{% step %}

### Adjust for discounts and different client types

If you have materially different rates or discounts by client type or channel, you can model this by either:

* Creating separate rate drivers and revenue variables per client segment, for example:
  * `Rate - Consultant - London - Enterprise`.
  * `Rate - Consultant - London - SME`.
* Or using discount drivers that modify the base rate, for example:
  * `Effective Rate = Base Rate × (1 minus Discount Percentage)`.

Keep segment definitions as simple as possible to avoid a proliferation of variables.
{% endstep %}

{% step %}

### Integrate project pipeline and scheduling

To tie revenue more directly to work in the pipeline, you can connect billable hours to project schedules by:

* Using Pipeline drivers for expected hours per project and period.
* Allocating those hours to roles and branches.
* Ensuring that allocated hours reconcile with total billable hours capacity.

This approach is described in more detail in **Project Pipeline and Revenue Scheduling** and will allow you to check that the combination of rate card, hours and pipeline assumptions are consistent.
{% endstep %}

{% step %}

### Build rate and revenue dashboards

Create a dashboard that shows:

* Rate per role and office over time.
* Total billable and realised hours per role and branch.
* Revenue per role, office and practice.
* Revenue per FTE or per billable hour as key KPIs.

Use this dashboard to answer questions like:

* What happens to revenue if we increase rates by a certain percentage.
* How much of revenue growth comes from increased rates versus increased hours or headcount.
* How does rate and mix differ between offices or service lines.
  {% endstep %}
  {% endstepper %}

## Check your work

* Rate drivers match actual or planned rate cards used by the firm.
* Billable hours calculations align with utilisation expectations and past performance.
* Revenue per branch and role looks sensible when compared to historical data where available.
* Rate changes and hiring plans produce revenue patterns that match your expectations.

## Troubleshooting

<details>

<summary>Revenue jumps unexpectedly when rates change</summary>

Confirm that rate changes are scheduled correctly and that there are no overlapping or duplicated rate drivers.

</details>

<details>

<summary>Too many rate combinations create complexity</summary>

Rationalise the rate card to a smaller number of bands and only use detailed exceptions where they really matter.

</details>

<details>

<summary>Difficult to reconcile to time and billing systems</summary>

Use exports from those systems to calibrate your hours and realisation assumptions, but keep the planning model focused on drivers and aggregates rather than transactional detail.

</details>

## Related guides

* [Build a Synergy & Integration Model](/how-tos/investment-and-transactions/build-a-synergy-and-integration-model.md)
* [Build a Terminal Value Model](/how-tos/valuation/build-a-terminal-value-model.md)
* [Discount Rate Modifiers](/help/financial-outputs-and-valuation/discount-rate-modifiers.md)
* [Entering Delays](/syntax/timing-syntax/entering-delays.md)