Time Tracking in a Business App: What Should Start, Stop and Approval Mean?

2026-10-24

Before commissioning time tracking, separate three decisions: when time was recorded, whether someone reviewed it and whether it can be charged to a customer. A stopped timer answers only the first question. It should not silently approve work or authorise an invoice.

For a small team, a useful starting point is a timer plus manual entry, an obvious running state and a correction process. Add submission and approval only where your actual work needs them. The choices below are requirements to discuss, not payroll rules or a promise that any particular product includes the complete workflow.

Decide what a time entry represents

Record whose work it is and which job it belongs to. Decide whether a description is compulsory and whether breaks belong outside the entry or appear as explicit deductions. Otherwise two people can record similar work in incompatible ways.

Keep elapsed time separate from the amount eventually charged. A customer may have agreed a fixed fee, a minimum charge or another arrangement. Those commercial terms should not be inferred from a stopwatch.

Toggl Track provides a useful documented example of the distinction: its time-entry API describes a duration, start and stop fields, and a separate field indicating whether the entry is marked billable. That documents the data model, not a guarantee that a billable entry has been reviewed, accepted by the customer or included on an invoice.

Make the running timer a shared state, not just an animation

Ask what happens if someone starts a timer on a phone and later opens the same account on a laptop. Both screens should reflect the agreed saved state. Closing the app should not count as stopping unless that unusual behaviour is explicitly intended and explained.

Choose a policy for overlapping entries. One active timer per person is a simple option for discussion, but not a universal requirement. If parallel timers are allowed, agree how reports will distinguish recorded intervals from a person's total working time. Do not simply sum overlapping entries and label the result hours worked without a defined policy.

For Toggl's API specifically, the documentation describes running entries using a negative duration and notes that the stop field can be null for a running entry or an entry created with duration and duronly fields. A missing stop value alone is therefore not a universal way to infer the business state. Your developer should map the chosen provider's documented representation deliberately.

Handle forgotten timers without guessing the answer

A timer left running overnight needs attention, not an invented finishing time. Decide when the app should flag a long entry, who receives the flag and whether the entry stays out of approval until corrected. The threshold is an operational choice, not proof that work beyond it is invalid.

If the app suggests a correction, show it as a suggestion. Preserve the recorded interval and the reason for an accepted change according to your agreed history and retention policy. A person should be able to distinguish what the timer captured from what a reviewer later accepted.

Manual entries need an equally clear path. Allow staff to record legitimate work when they forgot to start a timer, while identifying the entry as manually supplied rather than pretending it came from a running clock.

Design the review boundary before adding an Approve button

An uncomplicated process might have editable entries, a submitted period and a reviewed result. Define the transitions rather than relying on labels:

Can a running entry be submitted? If not, explain how to resolve it.
Can a reviewer amend an entry, or only return it for correction?
Does changing a submitted entry reopen review?
Can a completed period receive a late entry, and who decides?
What happens when the associated job is closed or the staff account is deactivated?

Approval should refer to an identifiable set of entries or versions. Otherwise the approved total could change later while still displaying the old approval. If corrections are needed after export or invoicing, agree a reconciliation process rather than silently replacing what another system already received.

These are proposed controls for the commissioned app. They are not claims about Toggl's approval or invoicing features.

Test a small story from beginning to end

Use fictitious staff and jobs. Start a timer on one device, inspect it on another, stop it and then add a manual correction. Submit the period, return one entry for revision and review the corrected result. Check that each screen uses the same time basis and that midnight or a change of time zone does not quietly move work into an unexpected reporting period.

You do not need a large test database. You do need explicit expected results. Include these cases in your project acceptance criteria:

A second start follows the chosen overlap policy.
Repeating a stop request does not create another entry or increase the recorded duration.
A forgotten timer is flagged without fabricating hours.
Manual and timer-based entries remain distinguishable where required.
Editing reviewed work triggers the agreed correction and review path.
Billable, approved and already exported remain separate concepts.

For a custom business app, bring a blank example of the time report you actually need. Decide who uses each column and what action follows it. That is a better starting point than asking for a timer and discovering the billing rules afterwards.

Source and limits

Toggl Track Engineering, Time entries: https://developers.track.toggl.com/docs/track/api/time_entries/

The source supports the described fields and running-entry representation. Device consistency, overlap handling, corrections and approval boundaries are practical specification recommendations. Employment, payroll, retention and contractual charging obligations depend on your circumstances and require appropriate professional advice; this guide does not establish compliance.