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.