> ## 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.

# Budget vs estimate: what is the difference?

> An estimate is on a task and predicts effort. A budget is on a project and caps spend. Learn how the two differ, how they interact, and when to use each.

These two words get used as if they mean the same thing. In TimeTracker they are
different objects, on different things, with different jobs.

<CardGroup cols={2}>
  <Card title="Estimate" icon="ruler">
    Lives on a **task**. Predicts how long *this piece of work* should take.
  </Card>

  <Card title="Budget" icon="chart-pie">
    Lives on a **project**. Caps what *the whole engagement* may consume.
  </Card>
</CardGroup>

## The one-line version

> An **estimate** is a guess about effort. A **budget** is a limit on spend.

You can have one without the other. Many projects run with budgets and no estimates.
Some internal projects have estimates and no budget.

## Side by side

|               | Estimate               | Budget                   |
| ------------- | ---------------------- | ------------------------ |
| Sits on       | A task                 | A project                |
| Measured in   | Hours                  | Hours **or** money       |
| Purpose       | Predict effort         | Cap spend                |
| Set by        | Whoever plans the work | Whoever agrees the deal  |
| Typical owner | Project Manager        | Project Manager, Finance |
| Capability    | `task.reviseEstimate`  | `budget.manage`          |
| Resets        | Never                  | Optionally, every month  |
| Plan          | Free                   | Pro                      |

## An example with both

Northwind agrees a website redesign with Bluebird Coffee for **\$40,000**.

That \$40,000 is the **budget**. It sits on the project.

Priya then breaks the work into tasks and estimates each one:

| Task                     | Estimate  |
| ------------------------ | --------- |
| Discovery workshop       | 12 h      |
| Homepage wireframes      | 8 h       |
| Interior page wireframes | 20 h      |
| Visual design            | 60 h      |
| Build                    | 140 h     |
| QA and launch            | 24 h      |
| **Total**                | **264 h** |

Those are **estimates**. At an average $100/hour, 264 hours is about $26,400 of
billable value – comfortably inside the \$40,000 budget, with room for revisions.

Now the work happens. Sarah, Jonas and Ana record time against those tasks. Two
things are tracked in parallel:

* **Estimate vs actual, per task.** Homepage wireframes was estimated at 8 hours and
  took 11. That is useful for quoting the next job.
* **Budget burn, for the project.** $18,400 of the $40,000 is used. That is useful
  for knowing whether you are still making money *now*.

They answer different questions, which is exactly why both exist.

## How they interact

They are independent, with two connections:

1. **Estimates roll up.** The sum of task estimates gives you a bottom-up forecast
   you can compare against the budget before work starts. If your estimates already
   exceed the budget, you priced the job wrong – and you know on day one, not in
   month three.
2. **Task caps.** A task can carry its own cap that counts toward the project
   budget, for cases where one piece of work must not run away. See
   [task-level caps](/budgets/task-level-caps).

Otherwise, changing an estimate never changes a budget, and changing a budget never
changes an estimate.

## When to use each

**Use estimates when:**

* You want to know if a task is running long
* You are quoting future work and need past accuracy to learn from
* You are balancing workload across a team
* You want to spot the task that always takes twice as long

**Use budgets when:**

* A client agreed a fixed fee
* You sold a block of hours
* You run a monthly retainer
* You need an alert before a project stops being profitable

**Use both when** you want the full picture: budgets tell you if the *project* is
healthy, estimates tell you *which task* made it unhealthy.

## A third thing people confuse: the quote

A **quote** is what you told the client. A **budget** is what you enforce internally.
They are usually the same number, but they do not have to be.

Northwind quotes Bluebird $40,000 and sets an internal budget of $36,000, keeping
\$4,000 of headroom for revisions. The client sees the quote. The team works to the
budget, and the alert fires early enough to do something about it.

See [quote to invoice](/guides/quote-to-invoice).

## Which one is telling me I have a problem?

| Symptom                                     | Look at                                                        |
| ------------------------------------------- | -------------------------------------------------------------- |
| "This task is taking forever"               | The **estimate**                                               |
| "Is this project still profitable?"         | The **budget** and [margin](/budgets/profitability-and-margin) |
| "Will we finish on time?"                   | Remaining **estimates** against capacity                       |
| "Can we afford another round of revisions?" | Remaining **budget**                                           |
| "Did we quote this job correctly?"          | Estimate vs actual, across the project                         |

## Permissions

| Action                         | Capability                        | Roles that hold it            |
| ------------------------------ | --------------------------------- | ----------------------------- |
| Set or change a task estimate  | `task.reviseEstimate`             | Owner, Admin, Project Manager |
| Set or change a project budget | `budget.manage`                   | Owner, Admin, Project Manager |
| See budget burn in money       | `rate.viewBilling`                | Owner, Admin, Project Manager |
| See margin                     | `rate.viewCost` / `time.viewCost` | Owner, Admin                  |

Note that `task.reviseEstimate` is separate from `task.edit`. Someone can edit a
task's title and assignee without being able to move the number the plan depends on.

## Common questions

<AccordionGroup>
  <Accordion title="Can I have a budget with no estimates?">
    Yes, and it is common. The budget still tracks burn correctly – it counts what
    was recorded, not what was predicted.
  </Accordion>

  <Accordion title="Can I have estimates with no budget?">
    Yes. Internal projects often do. You still get estimate-vs-actual reporting.
  </Accordion>

  <Accordion title="If I change an estimate, does the budget move?">
    No. They are independent. Only recorded time moves a budget.
  </Accordion>

  <Accordion title="Should the sum of my estimates equal the budget?">
    Usually it should be a bit **under**. If estimates already fill the budget, there
    is no room for revisions or the work you have not thought of yet.
  </Accordion>

  <Accordion title="What happens when a task goes over its estimate?">
    Nothing is blocked. The estimate is a prediction, not a limit. It shows as an
    overrun so you can see it. Only a task cap actually constrains spend.
  </Accordion>

  <Accordion title="What happens when a project goes over budget?">
    Work is not blocked. The budget shows as over, and alerts fire if configured. See
    [budget alerts](/budgets/budget-alerts).
  </Accordion>
</AccordionGroup>

## Related guides

<CardGroup cols={2}>
  <Card title="How budgets work" icon="chart-pie" href="/budgets/how-budgets-work">
    Burn, periods and what consumes a budget.
  </Card>

  <Card title="Task estimates" icon="ruler" href="/tasks/task-estimates">
    Setting and revising the number on a task.
  </Card>

  <Card title="Hours vs money budgets" icon="scale-balanced" href="/budgets/hours-vs-money-budgets">
    Choosing which kind of budget to set.
  </Card>

  <Card title="Quote to invoice" icon="route" href="/guides/quote-to-invoice">
    The full journey from estimate to payment.
  </Card>
</CardGroup>