> ## Documentation Index
> Fetch the complete documentation index at: https://docs.francis.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Plan headcount

> How to set up a dedicated headcount sheet in Francis, forecast salaries, and keep the P&L in sync.

Salary forecasting involves enough moving parts (hire dates, increase cycles, pension rates, employer costs) that it needs its own sheet. A dedicated headcount sheet keeps the complexity contained and the P\&L clean.

## What approach to use

Driver-based is the right default for headcount. Salary costs are determined by known inputs you control directly: hire dates, salary levels, increase cycles, pension rates. Model them explicitly rather than projecting from history.

Use statistical when headcount is stable and salary increases follow a predictable annual pattern. It doesn't account for changes in the trend.

Hardcoded is for discrete, known costs that don't follow a formula: bonuses, one-off contractor fees, signing bonuses. Not the right fit for recurring salary costs.

## Where to forecast headcount

* **Dedicated sheet:** right for most cases. Salary data is sensitive, individual costs have multiple components, and a dedicated sheet gives you a single place to model and update across the team. The P\&L row references the total.
* **Directly on the P\&L:** right for simpler cases: a stable team on statistical, or a one-off cost like a bonus hardcoded to a specific month.

## Forecasting approaches

<Tabs>
  <Tab title="Driver-based">
    **Set up the sheet structure**

    Create a dedicated sheet with two sections: **Assumptions** at the top and salary totals below.

    In the **Assumptions** section, add rows for variables that apply across all employees: salary increase percentage, pension percentage, or any other shared inputs. These become the single inputs that drive calculations across the sheet.

    A common approach adds a group per employee or role with rows for base salary, pension, and other employer costs. Consider grouping employees into groups for departments.

    <Tip>If you use dimensions, you can break down actuals by department without splitting GL accounts into separate rows. The headcount sheet is primarily a forecasting tool: build your plan at the employee or role level, then reference the totals on the P\&L where they sit alongside actuals at the department level.</Tip>

    **Enter starting salaries**

    For each current employee, enter their monthly salary directly on the **Salary** row. This is the baseline the forecast builds from.

    **Forecast ongoing salaries**

    On each salary row, reference the prior month and apply the salary increase assumption:

    ```typescript theme={null}
    = "Salary"[-1] + ("Salary"[-1] * "Salary increase"[0])
    ```

    In months where the salary increase assumption is zero, the salary carries forward unchanged. When the assumption fires, the increase is applied automatically.

    **Model salary increases**

    The `if_month()` logic lives on the **Salary increase** row in the Assumptions section, not on the salary row itself:

    ```typescript theme={null}
    = if_month(6) * 3%
    ```

    This sets the increase to 3% in month 6 and zero in all other months. Adjust the month number and percentage to match your review cycle. Because every salary row references the same assumption, updating it in one place updates every employee automatically.

    **Add pension and employer costs**

    Reference the salary row and apply the pension percentage from the Assumptions section:

    ```typescript theme={null}
    = "Salary"[0] * "Pension %"[0]
    ```

    Add a row for other salary-related costs using the same pattern with the relevant percentage.

    **Model new hires**

    For a new hire joining mid-year, leave the **Salary** row empty for months before their start date. Enter their salary directly in the month they join, then apply the ongoing salary formula from the following month forward.

    <Note>As you move the Forecast Start date forward, periods that were forecast become actuals. Enter actual salary values for those periods on the headcount sheet. Formulas referencing prior months will break if the preceding actuals period is empty. If you don't have actuals, put the budget numbers into the actuals layer to avoid formulas breaking.</Note>
  </Tab>

  <Tab title="Statistical">
    The right fit for a stable workforce with predictable annual salary increases. If headcount is steady and increases follow a known pattern, a YoY reference with a growth rate captures the forecast accurately:

    ```typescript theme={null}
    = "Total salary cost"[-12] * (1 + 5%)
    ```

    Statistical loses individual visibility: you can't see specific salaries or model hires and departures. It breaks down when headcount is changing. New teams, rapid hiring, or significant restructuring all make the historical pattern an unreliable base.
  </Tab>

  <Tab title="Hardcoded">
    The right fit for discrete, known costs that don't follow a formula: bonuses paid at a specific time, a one-off contractor engagement, or a signing fee. Enter the value directly on the relevant row in the month it applies.

    For recurring salary costs, hardcoded values become a maintenance problem quickly: any hire, departure, or salary change requires a manual update across every future month. Use driver-based for those.
  </Tab>
</Tabs>