Time, Expenses & Projects

Recording Time and Expenses

A time entry is one piece of work: who, when, how long, and what it was for.

Time attaches to anything

An entry points at whatever it was for using the same pattern subtasks and the activity stream use. That means time can be booked against a project, a work order, a support case, an asset or any other datastore, without the time module needing to know what those things are.

Practically: you do not need a project to record time. If your business books time against jobs, cases or machines, the module works against those directly.

Rates are stored on the entry

Both the bill rate and the cost rate are resolved once, when the entry is made, and stored on the row.

This is important and occasionally surprising. If a rate card is edited in March, January's entries keep January's rates. The alternative — looking rates up at report time — means editing a rate card silently restates every historical margin, so last quarter's profitability changes because somebody updated a price. Storing the rate makes history stable.

The consequence to be aware of: correcting a genuinely wrong rate on past entries is a deliberate operation, not a side effect of fixing the card.

Billable and non-billable

Capture non-billable time too. Utilisation is only meaningful if the denominator is real, and a system that records only billable hours cannot tell you where the rest went.

Timesheets

Entries are grouped into a timesheet for a period, submitted, and approved or rejected as a unit. The submission carries the approval decision, so you can tell approved time from time merely entered — which is what invoicing should depend on.

Expenses

Expenses follow the same shape: recorded against the same scope, marked billable or not, and carried through the same approval. Where an expense is rebilled with a markup, record both the cost and the rebill so margin remains visible.

Practical advice

Make entry quick and daily. Time reconstructed at the end of the month is fiction, and no amount of downstream sophistication rescues an inaccurate input.

Rate Cards

A rate card supplies the bill rate and cost rate applied to a time entry. Several may apply at once, and the most specific wins.

How a card matches

A card can be qualified by resource, scope, activity and role. Leaving a column empty means "any", so a card with everything empty is the fallback that applies when nothing more specific does.

Specificity scoring

Where several cards match, each is scored and the highest wins. The weightings are fixed and worth knowing, because they tell you which qualification is treated as most authoritative:

• Resource — 8
• Scope — 4
• Activity — 2
• Role — 1

Resource outranks everything: a rate agreed for a named person applies even where a project rate exists. Scope beats activity and role, so a rate negotiated for a particular client project overrides a general rate for that kind of work.

Because the weights work like binary place values, a single more-significant qualification always beats any number of less-significant ones. A card matching only on resource beats one matching on scope, activity and role together.

Building a set

Start with one fallback card covering everything, then add specific cards only where a genuine agreement exists. A small set resolves predictably; a large one produces rates nobody can explain to a client.

Testing

Before going live, record a test entry for each combination that matters and confirm the resolved rate. The cases to check are where two cards are close in specificity — that is where a surprise lives.

Changing rates

Remember that rates are stored on entries at the moment they are recorded. Editing a card changes future entries only. If a new agreed rate should apply from the start of the month and entries already exist, those entries need correcting deliberately — the card edit will not reach back.

Projects, Budgets and Billing Plans

A project ties work, cost and billing together. As with everything else here, it attaches to the task datastore you already have rather than replacing it.

Work breakdown

A work breakdown structure arranges your existing task rows into a coded tree, so a project has phases, phases have deliverables, and time and cost roll up through the levels. The tasks stay where they were; the WBS is the arrangement over them.

Budgets are versioned

Budgets are held by cost type, and superseding a line keeps the old one rather than overwriting it. So a project retains its budget history — what was approved originally, and what it became after each change.

This matters at the end of a project that went over. "We were 40% over budget" and "we were 40% over the original budget, having revised it twice" are different statements, and only a versioned budget can distinguish them.

Billing plans

How a project bills is declared as its plan:

• Time and materials — bill what is recorded, at the resolved rates.
• Capped time and materials — as above, up to a ceiling. Work beyond the cap is recorded but not billed.
• Fixed price — an agreed sum regardless of effort. Time is still recorded, because that is how you learn whether the price was right.
• Milestone — billed on the achievement of defined points.
• Retainer — a recurring amount, with rules for whether unused time carries forward.

Billing events

Every billing run writes an event. That record is what lets a capped plan know its remaining headroom, and what gives you a history of what was billed when and on what basis.

For capped work, watch the headroom during delivery rather than at the end. The cap is only useful as a warning if somebody sees it coming.

Choosing a plan

Match the plan to the commercial agreement rather than to what is convenient to configure. A fixed-price job run as time and materials will bill the client something they did not agree to, and the discovery happens at invoice.