Rates and pay reports

Time tracking records hours. This page is about turning those hours into money — and about deciding, carefully, who gets to see it.

Everything here is admin territory for setting, and a separate grant for seeing.

The rate grid

Rates live in one grid: people down the side, activities across the top.

An activity is the kind of work — Design, Development, Consulting, Support. Whatever your team bills or costs differently.

	Design	Development	Support
Marina	90	—	60
Tomás	—	110	60

A blank cell means no rate for that pairing, not zero. If Tomás never does design work, leave it blank — a 0 would quietly make his design hours free instead of unpriced.

Only full members appear in the grid. Guests never do.

Why per activity, not per person

Because one person is worth different amounts doing different things, and a single blended rate hides that.

An agency billing design at 90 and support at 60 cannot express that with one number per person. It ends up either overcharging for support or undercharging for design — and then somebody maintains a spreadsheet on the side, which is the thing you bought a tracker to stop.

Currency

There is a workspace currency, and each person can be set to their own.

That matters for distributed teams and contractors: a contractor invoicing in EUR does not have to be converted by hand into your reporting currency before the numbers mean anything.

The pay report

Once rates exist, the report folds every logged block into money.

For each person you get:

total hours
total cost
a breakdown per activity, so you can see where the money actually went

And a CSV export, because at some point this has to reach a spreadsheet or an accounting system.

Overlaps are flagged, not silently doubled

If someone’s time blocks overlap — two timers running, or a manual entry across a tracked period — the report says so instead of quietly billing the same hour twice.

That warning is the whole reason to trust the total. A report that cannot be wrong is a report nobody checks.

Who can see money

Two independent switches. Both must allow it.

1. Pay visibility. Set at the workspace level, with a per-person override.

Setting	Effect
Workspace visible	Money is on by default
Workspace hidden	Money is off for everyone except admins
Person: inherit	Follows the workspace setting
Person: visible	This person sees money regardless
Person: hidden	This person never sees money

Admins always resolve to visible.

The critical detail: when pay is hidden, amounts never reach the browser. They are not blurred, not display: none, not sitting in a JSON payload waiting to be inspected. They are absent.

This is what makes dotby usable for agencies. Your freelancer sees their own hours and no rates; your client sees their project and not your margin.

2. The pay.viewAll capability. Seeing other people’s money is a separate grant an admin gives a manager, from their row in the member roster.

It is deliberately split from time.viewAll, which shows everyone’s hours with no money attached. “HR sees hours, finance sees money” is the normal division, and bundling them recreates the problem capabilities exist to solve.

See Roles and permissions.

Setting rates stays admin-only

Granting pay.viewAll lets a manager read the report. It does not let them change what anybody costs. Editing the rate grid is admin-only, always.

That split is on purpose: reading a number and setting a number are very different amounts of trust.

A sensible setup

For an agency or a contractor-heavy team:

Define your activities before your rates. The activity list is the hard part; the numbers are easy.
Turn workspace pay visibility off.
Grant pay.viewAll to whoever does invoicing. One person, usually.
Grant time.viewAll to whoever runs delivery, so they can see load without seeing cost.
Leave everyone else with their own hours and nothing else.

Track time — where the hours come from.
Roles and permissions — the capability that unlocks the report.
Plans and billing — dotby’s own bill, not your client’s.