Roles, Rates & Project Budgets
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 your 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 over time, and a report for last March should still use March's rates. Every rate is therefore 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:
Change — from a date onward
Closes the current period and opens a new one from the date you choose. Work before that date keeps its old price, so past reports do not move. This is what you want for a raise or a new agreed rate.
Correct — rewrite an existing period
Edits the values of a period already on record. Reports covering it recalculate. Use this only when the rate was entered wrong, not when it genuinely changed.
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, so nothing is priced at the new rate yet.
- A project override outranks the organisation rate for that project — see below.
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 exactly 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 you can use Override since the beginning to date 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
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 would read Below margin goal; against a 10% goal, On track.
What the colours mean
Margin is at or above the goal. With no goal set, simply profitable and within budget.
Still profitable, but earning less than the project was meant to. Delivery has passed the cost ceiling the goal implies.
Billed past the quoted price, with no goal set to judge it against. Set a margin goal to get a sharper signal.
Delivery has cost at least what the client is paying. Every further hour is a loss. This can happen before the budget is fully consumed on a thin-margin project.
Some logged work could not be priced — its job role has no rate, or the person has since left the organisation — so the position cannot be calculated. A project shows this instead of On track whenever any of its hours went unpriced: the figures are then 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 & 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
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 live on Reports → Summary → Billing.