Time & work items
In the Efimis UI, a fee-earning employee records Time for an activity they perform. In the public API, each Time record is called a work item.
Most work items belong to a matter and can contribute to work in progress and an invoice. Efimis also supports non-billable work, administrative work, and leave.
Work items preserve the activity originally recorded separately from later billing decisions. This allows the firm to report the work performed even when an invoice writes its value up, writes it down, or does not charge the client for it.
Work item types
Section titled “Work item types”The API distinguishes three item types:
| Type | Meaning |
|---|---|
| Timed fee | Work measured by elapsed time and valued using a time-based rate. |
| Itemised fee | Work measured in units and valued at a rate per unit. |
| Leave | Employee time recorded as leave rather than client work. |
Billable versus non-billable is not the same distinction as timed versus itemised. A timed or itemised fee can become billable or non-billable according to the matter, task type, and work-item workflow.
Core fields
Section titled “Core fields”A work item can identify:
- the matter to which the work relates;
- the employee who performed it and the employee’s team;
- the entry date—the date on which the work was done;
- a task type and title or narrative;
- elapsed duration and billing units;
- the applicable rate and total value;
- the invoice containing the item, once billed; and
- its current lifecycle state.
The API represents elapsed duration as durationTicks and also exposes units. The number of minutes represented by a unit depends on firm and matter policy. Do not assume that one unit always means six minutes or that the stored duration is itself a number of minutes.
Task types and rates
Section titled “Task types and rates”A task type categorises common work. It can provide a code, display name, item type, and default narrative. Task types make time recording consistent and help integrations select the correct billing treatment without embedding a firm’s configuration in code.
The applicable rate can depend on several inputs, including the matter, client, employee, date, and task type. Use configured task types and the applicable-rate lookup rather than maintaining a duplicate rate table in an integration.
Rates and totals can contain both transaction and firm-base-currency values. Preserve the values returned by Efimis for historical and management reporting.
Recorded value and billed value
Section titled “Recorded value and billed value”Finalising a work item recognises it as completed work available to later processes. Billing then associates it with an invoice. An invoice can adjust how much of that work is charged without rewriting the original record of what the employee did.
This distinction supports several common cases:
- bill the recorded units and rate without adjustment;
- write a fee up or down on the invoice;
- show a zero-value line to the client while retaining the recorded work;
- mark matter-related work as non-billable; or
- record internal work against an administrative or non-billable matter.
Credit notes, cash allocations, and invoice write-offs occur after billing and should remain separate from the work item’s recorded value.
Lifecycle
Section titled “Lifecycle”The work-item states describe its progress from entry to billing:
| State | Meaning |
|---|---|
| Pending | The item can still be edited and is not yet finalised. |
| Finalised | The work has been confirmed and can proceed to billing or reporting. |
| Drafted | The item has been placed on a draft invoice. |
| Billed | The item is included on an issued invoice. |
| Written off | The firm has decided not to recover the recorded value. |
| Non-billable | The work is retained for reporting but will not be charged. |
| Deleted | The pending item has been removed from ordinary use. |
The public API provides explicit operations to finalise, unfinalise, delete, and restore work items. Deletion is limited to unfinalised work; do not treat deletion as a way to reverse billed financial activity.
Unfinalising returns eligible work to an editable state. It can fail when downstream billing activity means the transition is no longer valid, so integrations should surface the API’s result rather than assuming every finalised item can be reopened.
In the REST API
Section titled “In the REST API”Work-item endpoints support searching by matter or employee, creating, reading, updating, deleting unfinalised items, finalising, unfinalising, and restoring. Task-type and applicable-rate endpoints provide supporting configuration.
See the REST API reference for current fields and operations. Continue with Invoicing & ledger to see how finalised work becomes a client charge.