Skip to content
Timesheet Systems

All notes  /  04 · Integrations

Feeding Billing

Time becomes an invoice through several decisions the timesheet system may or may not make. Where the rate lives, and what happens when it changes.

Procedure

The path from a recorded hour to an invoice line involves rates, increments, write-offs and currency. Which system makes each decision determines where the arguments happen.

Where the rate lives

In the timesheet system: simple to report on, and it becomes another place to maintain rates.

In the billing or practice management system: single source, and the timesheet system cannot show value.

In both: they diverge, and an invoice disagrees with a report.

Decide once. The common answer is that billing owns rates and the timesheet system sends hours with enough attribution to price them.

Rate complexity to check for

Rate by person, by role, by client, by matter, by activity — most organisations use at least two of these together.

Effective dating. A rate change in April must not reprice January's work, and many products get this wrong.

Overrides at matter level, with a record of who approved them.

Currency, where clients are billed in more than one, including which rate applied on which date.

Ask the vendor to demonstrate a rate change that does not retroactively alter closed periods. This is the test that separates products built for professional services from products with a rate field.

Increments and rounding

Billing increments differ from payroll rounding and both apply to the same underlying record.

Which is the argument for storing raw time and applying each at calculation.

Ask whether increment is configurable per client, since clients frequently impose their own in the engagement terms.

Write-offs

Recorded time not billed needs to remain visible as effort even after it is removed from an invoice.

A product that deletes written-off time destroys the costing data, and the finding that the work is underpriced with it.

Require: write-off as a flag with a reason code, not a deletion.

Approval and lock

Time approved for billing should lock, so an invoice cannot be contradicted by a later edit.

Unlocking should require authority and leave a record.

Ask what happens to an invoice already issued when underlying time changes. Silence here means the systems will disagree and nobody will notice until a client does.

Testing it

Bill a matter with two rates, a mid-period rate change and a write-off.

Check the invoice, the effort report and the costing figure agree on the underlying hours while differing appropriately on money.

Change a closed period and see what the invoice does.

Run a credit note, which is the case nobody tests and everybody eventually needs.

The effective-dating test

The demonstration that separates products built for professional services from products with a rate field.

Ask them to change a rate with an effective date, then re-open a closed period from before that date.

The old work must still price at the old rate.

Many products reprice everything, which turns a rate rise into a retrospective invoice adjustment.

Test it during the trial with your own dates, because this is not something a demonstration script will cover.

Follow an hour into the invoice

Client work exposes rate, write-off and correction edge cases quickly. You can learn more about the approach, then reproduce the complete invoice trail using representative contracts.