Rates and project budgets - Clocktopus Docs

Tracked hours become money through three layers: a job role carries the rates, a project can override them, and a budget says how much of it the work is allowed to consume.

Job roles

A job role belongs to an organisation and carries two hourly rates in the organisation's currency.

Sell rate — what an hour is worth to the client. Drives revenue, and how fast a budget is consumed.
Cost rate — what that hour costs you to deliver. Drives margin; the difference is what the project keeps.

Every member is assigned one role per organisation, and each organisation has a default role that new members inherit. An hour is priced by the role of whoever logged it, so the same work costs different amounts depending on who did it.

A member with no job role has no rate. Their hours are still tracked and still appear in time reports, but they cannot be priced — reports show — rather than counting them as zero. Unpriced work is unknown, not free. The same applies to anyone removed from the organisation: their past hours stay in the time reports but lose the role that priced them.

Rates are effective-dated

Rates change, and a report for last March should still use March's rates. Every rate is stored as a period with a start and an end, and an hour is priced at whatever was in effect on the day it was worked — never at today's rate.

That gives you two different operations, and picking the wrong one is the most common source of confusion.

Operation	What it does	Use it when
Change — from a date onward	Closes the current period and opens a new one. Work before that date keeps its old price, so past reports do not move	A raise, or a newly agreed rate
Correct — rewrite an existing period	Edits a period already on record. Reports covering it recalculate	The rate was entered wrong

If a rate change seems to do nothing, it is almost always one of these:

The change starts today, but the hours you are looking at were worked earlier. They keep the old rate, by design.
No hours have been logged since the date the change takes effect.
A project override outranks the organisation rate for that project.

Project rate overrides

A project can override a role's rates for its own work — a client negotiated a different price, say. Overrides are effective-dated in the same way, and everyone holding that role bills at the override on that project.

When pricing an hour, the first rule that matches wins:

The project override for that role, if a period covers the day the work was done.
Otherwise the organisation rate for that role, for the period covering that day.
Otherwise no rate, and the hour is reported as unpriced.

Because overrides are dated, an override starting in July leaves June billing at the organisation rate. When creating a first override, Override since the beginning dates it from the project's creation so the whole project is priced consistently.

Project budgets

A budget is a single amount set on the project — what the client is paying. It is consumed by every hour ever logged to that project, priced at sell rates, across everyone who worked on it.

No reporting period. A budget covers the project's whole life, so the figure never changes with a date filter. The Budgets report has no range selector for that reason.

One budget per project. There are no budget periods or renewals. If the work needs a fresh budget, create a new project — the reporting boundary then matches the delivery boundary.

Budgets are available on organisation projects only. Consumption is priced from job-role rates, and a personal project has no organisation, so no roles and no rates to price it with.

Margin goal

The spread between a role's sell and cost rates is how you price labour. It says nothing about what a particular engagement was supposed to earn, so a project can carry its own target margin, and that is what its health is measured against.

A goal is really a spending limit. Setting 30% on a $12,000 budget says delivery must stay under $8,400 — the project settings screen shows that ceiling as you type.

A worked example


Budget (what the client pays)	$7,000.00
Consumed — 46.8 h at sell rates	$7,656.21 (109% of budget)
Cost — the same hours at cost rates	$6,040.11
Profit left = budget − cost	$959.89 (13.7% margin)

This project is over budget — $656.21 of work was done that cannot be invoiced — and yet it is still profitable, because the client pays $7,000 and delivery cost $6,040.11. Those are two different lines. Against a 15% goal it reads below margin goal; against a 10% goal, on track.

What the statuses mean

Status	Meaning
On track	Margin is at or above the goal. With no goal set, simply profitable and within budget
Below margin goal	Still profitable, but earning less than the project was meant to. Delivery has passed the cost ceiling the goal implies
Over budget	Billed past the quoted price, with no goal set to judge it against. Set a margin goal for a sharper signal
No margin left	Delivery has cost at least what the client is paying. Every further hour is a loss — and this can happen before the budget is fully consumed on a thin-margin project
No rate	Some logged work could not be priced, so the position cannot be calculated. A project shows this instead of on track whenever any of its hours went unpriced: the figures are a floor, and unpriced work can only make them worse

Who sees what

Money is restricted per organisation and per project — being an admin of one organisation tells you nothing about another.

Owners and admins see and set rates and budgets, and see every amount: revenue, cost, margin and profit, for their own organisation's projects.
Members see how far through its budget a project is, as a percentage, and its health. Amounts are removed before the data leaves the server.

Where to set this up

What	Where
Job roles and organisation rates	Settings → Organisations
Budget, margin goal and rate overrides	Settings → Projects, on the project itself
Where each project stands	Reports → Budgets
Revenue, cost and margin over a date range	Reports → Summary → Billing