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

# How rates are chosen

> When a task, project, person and client all carry a rate, one wins. The exact order TimeTracker uses to price an hour, plus how the currency is picked.

The most specific rate wins. The order is **task → project → person → client**. The first level that has a rate is used, and the rest are ignored.

## The precedence order

<Steps>
  <Step title="1. Task rate">
    A rate set on the task itself. This beats everything else. There is no field for it on the task form today, so most workspaces never have one.
  </Step>

  <Step title="2. Project rate">
    That person's rate on that project. Set on the project's **Team** table under **Project rate**.
  </Step>

  <Step title="3. Person rate">
    That person's normal rate. Set at **Settings** → **Rates**. This is the level most workspaces use.
  </Step>

  <Step title="4. Client rate">
    The client's **Default rate (per hour)**. A flat figure for everyone working on that client's projects.
  </Step>

  <Step title="No rate found">
    The entry is saved with no billable value. It is not priced at zero – it is unpriced.
  </Step>
</Steps>

<Warning>
  There is no workspace-wide default rate. If no level has a rate, the hour has no money value. TimeTracker never invents a rate and never falls back to zero.
</Warning>

## Cost rates do not have an order

Cost has only one source: the **person** cost rate. There is no task, project or client cost override, so there is nothing to resolve.

| Level   | Billable                | Cost                |
| ------- | ----------------------- | ------------------- |
| Task    | Wins over all           | –                   |
| Project | Beats person and client | –                   |
| Person  | Beats client            | **The only source** |
| Client  | Last resort             | –                   |

## The date matters too

Every rate has an **Effective from** date, and every level is resolved for the **date of the time entry**, not today.

TimeTracker takes the newest row at each level whose effective date is on or before the entry's date. A row dated in the future is ignored until its date arrives.

Dates are handled as whole days, so a rate effective 1 April applies to work recorded at any hour on 1 April.

## Worked example

Sarah Lin tracks 4 hours on the Bluebird Coffee – Website Redesign project on **10 March 2026**.

| Level                      | Value on 10 March | Wins?   |
| -------------------------- | ----------------- | ------- |
| Task                       | none              | –       |
| Project (Website Redesign) | 110.00 USD        | **Yes** |
| Person (Sarah)             | 100.00 USD        | Ignored |
| Client (Bluebird Coffee)   | 120.00 USD        | Ignored |

`4 × $110 = $440`.

Now Sarah tracks 4 hours on **Fenwick Legal – Brand Refresh** on the same day. That project has no override and Fenwick Legal has no default rate:

| Level          | Value      | Wins?   |
| -------------- | ---------- | ------- |
| Task           | none       | –       |
| Project        | none       | –       |
| Person (Sarah) | 100.00 USD | **Yes** |
| Client         | none       | –       |

`4 × $100 = $400`.

Her cost is the same in both cases: `4 × $45 = $180`. Cost never varies by project.

## How the currency is chosen

The currency comes from the **level that won**, not from the workspace.

| Situation                                   | Currency used                                          |
| ------------------------------------------- | ------------------------------------------------------ |
| The winning rate has a currency             | That currency                                          |
| The winning rate has no currency of its own | The workspace base currency                            |
| No rate resolved at all                     | None – the entry has no billable value and no currency |

A task rate is a number only, so an entry priced by a task rate uses the workspace base currency.

Set your base currency at **Settings** → **General** → **Base currency**. See [/rates/currencies-and-exchange-rates](/rates/currencies-and-exchange-rates).

## When a rate is applied

The rate is resolved **once**, when the time entry is saved, and stored on the entry. Nothing re-resolves it later.

That is why editing a rate does not restate an old entry, and why the number on an invoice never drifts. See [/rates/rate-snapshots](/rates/rate-snapshots).

## Diagnosing a number that looks wrong

Work down the list in order. The first level with a rate is your answer.

<Steps>
  <Step title="Check the entry's date">
    Rates resolve for the day the work was done. A rate effective 1 April does not price work from 20 March.
  </Step>

  <Step title="Check the project override">
    Open the project → **Settings** → **Team**. If the **Project rate** column shows a figure for that person instead of **Inherits**, that is the winner.
  </Step>

  <Step title="Check the person rate">
    Open **Settings** → **Rates** and read the rate in force on the entry's date, not today's rate. The **Rate history** table shows every dated row.
  </Step>

  <Step title="Check the client default">
    Open the client record and look at **Default rate (per hour)**.
  </Step>

  <Step title="Check the entry itself">
    The entry was priced when it was saved. If a rate was added afterwards, the entry still carries the old figure – or none at all.
  </Step>
</Steps>

## Permissions

| Action                          | Capability         | Default roles                 |
| ------------------------------- | ------------------ | ----------------------------- |
| See which billable rate applies | `rate.viewBilling` | Owner, Admin, Project Manager |
| See the cost rate that applies  | `rate.viewCost`    | Owner, Admin                  |
| Change any rate                 | `rate.manage`      | Owner, Admin, Project Manager |

A request for the resolved rates returns the cost figure only to someone who holds `rate.viewCost`. See [/rates/rate-permissions](/rates/rate-permissions).

## Common questions

<AccordionGroup>
  <Accordion title="Is there a workspace default rate?">
    No. The workspace sets the base **currency**, not a rate. If no level has a rate, the hour is unpriced.
  </Accordion>

  <Accordion title="Does a client rate override a person rate?">
    No – it is the other way round. The person rate is more specific, so it wins. A client rate only applies to people who have no rate of their own.
  </Accordion>

  <Accordion title="Can I have a project rate for one person and inherit for everyone else?">
    Yes. The override is per person, per project. Anyone left on **Inherits** falls through to their person rate.
  </Accordion>

  <Accordion title="What if two rates share the same effective date?">
    The most recently added of the two is used. Remove the one you do not want from **Rate history** rather than leaving both.
  </Accordion>

  <Accordion title="Why does one entry have a currency and another does not?">
    An entry only has a currency when a rate resolved. An unpriced entry has neither.
  </Accordion>

  <Accordion title="Does the rate follow the person or the assignee of the task?">
    The person who tracked the time. Rates price whoever did the work.
  </Accordion>
</AccordionGroup>

## Troubleshooting

| Symptom                                         | Likely cause                              | Fix                                                            |
| ----------------------------------------------- | ----------------------------------------- | -------------------------------------------------------------- |
| An entry is worth nothing                       | No level has a rate for that date         | Add a person rate with an effective date on or before the work |
| The figure is higher than the person rate       | A project or client rate is winning       | Check the project **Team** table and the client record         |
| A new rate did not change old numbers           | Entries snapshot their rate               | Expected – see [/rates/rate-snapshots](/rates/rate-snapshots)  |
| The rate applied a day late                     | The effective date is after the work date | Add a row with the correct effective date                      |
| Two people on the same project bill differently | Person rates differ                       | That is normal. Use a project or client rate to flatten it     |

## Related guides

<CardGroup cols={2}>
  <Card title="Billable rates" icon="dollar-sign" href="/rates/billable-rates">
    What the winning rate produces.
  </Card>

  <Card title="Cost rates" icon="wallet" href="/rates/cost-rates">
    Why cost has no order.
  </Card>

  <Card title="Project and client rates" icon="folder-open" href="/rates/project-and-client-rates">
    The two override levels.
  </Card>

  <Card title="Set a person rate" icon="user-pen" href="/rates/set-a-person-rate">
    The level most workspaces use.
  </Card>

  <Card title="Rate snapshots" icon="camera" href="/rates/rate-snapshots">
    Why the answer is fixed at save time.
  </Card>

  <Card title="Currencies and exchange rates" icon="globe" href="/rates/currencies-and-exchange-rates">
    How the currency is decided.
  </Card>
</CardGroup>