15 Questions Employers Should Ask Before Buying Time-Tracking Software

A polished demo is the easiest part of buying time-tracking software. The hard part starts after a missed clock-out, a disputed screenshot, a failed sync, or an approved timesheet that changes five minutes before payroll.

That is why a feature checklist is not enough. “Has approvals” tells you nothing about who can reopen an approved record. “Works offline” does not tell you what stops working without a connection. “CSV export” does not prove you can leave with a complete history.

I think a vendor should lose the point if it says yes but will not show the edge case.

The answer in 60 seconds

Ask every shortlisted vendor the same 15 questions and record the proof beside the answer. Score the software on your real workflow, not the order of its demo.

• Start with the management decision the data is meant to support
• Define what may be collected before comparing monitoring features
• Test a failed sync, a correction after approval, and a complete export
• Include implementation, support, migration, and internal review time in the cost
• Treat a roadmap answer as “not available” until the feature is live
• Reject a tool if workers cannot see or challenge records that affect pay or performance

The product behaviors and public guidance linked below were checked against current primary sources on July 22, 2026. We did not run every product in production, which is why the proof request matters more than the brochure.

The 15-question buying scorecard

This is the Kordano Proof Before Purchase scorecard, a working framework for this guide rather than an industry standard. Give each question one of three marks: Pass, Needs proof, or Fail. Do not average away a failure involving pay accuracy, employee rights, data security, or the ability to leave.

Table: a quick scorecard for comparing time-tracking vendors on the same evidence.

Reading current help pages, I kept finding the important buying details below the feature headline: which role can edit, which state locks, and what the export leaves behind. The most useful lines were rarely on pricing pages. They were in approval, offline, and export documentation.

Before the demo: define the job

1. What decision will this data change?

Time tracking can support payroll, client billing, project costing, attendance, workload review, or a disputed entry. Those are different jobs. A system designed around shift attendance may be awkward for agency billing, while a project timer may not provide the controls payroll needs.

Write the decision before the requirement. “Payroll must know which submitted records are still missing approval at cutoff” is useful. “Managers need visibility” is not. The first statement names an owner, a moment, and an action. The second invites the vendor to show whichever chart looks best.

Ask the vendor to configure one report or queue around that decision. If nobody on your side will review the data or act on it, do not buy another dashboard.

2. Does it fit the work people actually do?

List the awkward parts of the week: shared workstations, phones with weak connections, overnight shifts, changing projects, paid breaks, contractors, multiple time zones, client codes, leave, and people who move between field and desk work.

Then give the vendor one realistic scenario. If an ecommerce operator had one afternoon to compare vendors, I would spend it on a failed sync, a changed approved timesheet, and a full export, not the dashboard tour.

The acceptable answer is not “we support flexible teams.” It is a live sequence showing how a person records time, how an exception reaches the right reviewer, and what payroll or billing receives at the end. If the demonstration requires a clean sample employee with a perfect week, it has not proved fit.

Before collection: set the data boundary

3. What exactly does the product collect?

Ask for a plain inventory: start and stop times, manual entries, idle periods, screenshots, app and website names, keyboard or mouse activity, device identifiers, IP addresses, location data, notes, edits, and manager actions. For each item, ask when collection begins, when it stops, what is stored, and who can see it.

Do not accept “non-invasive” as a technical description. A screenshot with blur still exists. An activity percentage still needs an input. A location feature may collect on a schedule that differs from the timer.

This is also a policy question. The UK Information Commissioner's Office says employers considering worker monitoring should identify a lawful basis, be clear about purpose, use the least intrusive means, tell workers what is happening, and complete a data-protection impact assessment when monitoring is likely to create high risk. Laws differ by location, so have qualified counsel review the rule that applies to your workforce. The ICO worker-monitoring guidance is still a useful test of whether a vendor can explain its data. Use the 2026 employee-monitoring laws guide to screen every US state and the main international hiring locations before rollout.

4. Can collection be limited to the people, hours, and work that need it?

The right question is not only whether a feature can be turned off. Ask whether settings can differ by role, team, project, working schedule, device, and type of day. Test whether capture stops when time stops, whether private time can be removed, and whether a manager can switch a sensitive setting without notice.

The NIST Privacy Framework gives organizations a way to connect privacy risk with business decisions. Applied here, that means collecting because a defined process needs the data, not because a vendor made the field available.

A control that exists only at the account level may force an employer to collect more than one team needs. That is a red flag. Buy for the minimum defensible data boundary, then expand only when a named use case justifies it.

5. Can employees see, explain, correct, and challenge records about them?

A worker should not first discover a changed time record on a payslip or a monitoring judgment in a performance meeting. Ask whether people can see their own entries, screenshots, activity data, location records, edits, rejection reasons, and approval status. Then ask what happens when they disagree.

The challenge path needs an owner and a deadline. It should preserve the original, the correction, the reason, and the decision. For data that affects pay, the timekeeping policy should say who may edit and when the employee is notified.

The consequences of getting the boundary wrong are not theoretical. In 2024, the UK ICO ordered Serco Leisure to stop using facial and fingerprint recognition for attendance at 38 facilities. The regulator found the processing unnecessary and disproportionate and said workers were not offered a clear alternative. The question for a buyer is simple: can people understand and contest the system that records them?

If screenshots are part of the answer, explain their purpose, access rules, retention period, and dispute process before turning them on.

During the demo: break the happy path

6. What happens offline, and what happens when the connection returns?

I expected offline mode to be a simple yes or no. One current help page lists five separate limitations.

Jibble's desktop offline documentation says people can continue tracking, but cannot select activities or projects, add breaks, receive reminders, or rely on every restriction while offline. It also explains how entries and screenshots synchronize later. That does not make the product good or bad. It proves that “offline” is a collection of behaviors.

Turn off the connection during the demo. Start and stop time, cross midnight, change a project, create two conflicting edits, and reconnect. Ask which device clock wins, how duplicates are prevented, whether restrictions are bypassed, and what the reviewer sees. If your team works in weak-connectivity areas, this test belongs before pricing.

7. What happens when a submitted or approved entry changes?

This is where “has approvals” stops being useful. Ask the vendor to approve a record, edit the hours, change a project, reopen the period, and approve it again. You should be able to see the old value, new value, editor, time, reason, and current status.

Deputy's current approval documentation says an approved timesheet must be unapproved before it can be edited. Its timesheet-history guide shows changes and who approved or edited the record. Clockify's approval guide likewise documents locking, withdrawal, rejection, and archived approvals. The details differ, which is exactly why the buyer must test them.

Any edit that changes pay, billing, leave, or the evidence behind approval should create a visible new decision. Quiet changes are a fail.

8. Who can view, edit, approve, export, and change settings?

Ask for the permission matrix, then test it with several ordinary accounts. The person who manages a schedule may not need pay rates. A project lead may need to approve client time without seeing another department. A payroll reviewer may need exports without permission to erase history.

A 2026 U.S. Government Publishing Office management letter gives a sharp example of why labels are not enough. In a sample of 45 timesheets, the auditors found one where the same supervisor served as timekeeper and certifier. They also reported that the system did not prevent that combination. The important buying lesson is not the sample size. It is that documented role separation should be enforced by the system and visible in its logs.

Ask who can impersonate a user, delete data, change capture settings, and export the whole account. Those actions deserve stronger controls than ordinary report viewing.

9. How does a pay period become ready for payroll or billing?

The vendor should show one queue with expected records, submitted records, approvals, rejections, missing people, open exceptions, and a control total. “Everyone is approved” is only useful if the system also proves who was expected.

Test a missing timesheet, an unresolved alert, a manager on leave, an entry crossing the pay-period boundary, and a change after the export was prepared. Decide who owns each exception and whether payroll can reject the handoff.

U.S. employers covered by the Fair Labor Standards Act have recordkeeping duties, although the law does not require one specific timekeeping method. The Department of Labor's Fact Sheet 21 says the records must be complete and accurate and describes retention periods for payroll and wage-computation records. Requirements vary across jurisdictions and worker types. The practical point is that a colorful dashboard does not replace a defensible record.

The process should define a full sequence for submission, review, approval, and handoff before payroll closes.

10. How do payroll, accounting, and project integrations fail?

Ask for the error, not just the connection. Change an employee identifier, remove a project, send the same period twice, reject one line, and make the receiving system unavailable. The vendor should show the failure message, retry behavior, duplicate protection, and reconciliation total.

An integration can move a bad record faster. It cannot decide whether the record was ready. Name the system of record for people, projects, schedules, approvals, and pay adjustments. Then document which side wins when values disagree.

A buying decision gets expensive when payroll, operations, and the team each thought the software promised something different. Put all three groups in the same edge-case demonstration. A clean export. All of it.

Before signing: price the relationship, not the seat

11. Where is the data stored, how long is it kept, and how is it deleted?

Ask where primary data and backups are hosted, which subprocessors receive it, how cross-border transfers are handled, how encryption keys and access logs are managed, and how long each data type remains after deletion or account closure.

Retention should attach to a reason. Screenshots may need a different period from payroll records. Audit events may need a different period from app-use details. Under the EU GDPR, the principles in Article 5 include data minimization and keeping identifiable personal data no longer than necessary for its purpose. Your applicable rule may be different, but “we keep everything indefinitely” is still a poor operational answer.

Request the security documentation and contract terms before procurement, not after a worker asks where their data went. If the vendor cannot name the deletion window for backups, mark Needs proof.

For the full review of purposes, vendor access, subprocessors, AI use, worker requests, export, and deletion, run the 12-question workforce data control audit.

12. What will the first year and second year really cost?

Calculate the cost at current headcount and a realistic growth case. Include minimum seats, inactive users, administrators, contractors, monitoring add-ons, payroll connectors, storage, implementation, support tiers, migration, training, contract term, renewal increase, taxes, and currency effects.

Then add internal work: manager review, correction, payroll reconciliation, employee support, policy changes, and manual rebuilding when an integration fails. A cheap timer can become an expensive weekly process.

Ask for a written quote covering both years and the price when a promotion ends. Confirm whether billing is monthly or annual, whether cancellation changes a discount, and whether every feature demonstrated sits in the quoted plan. The real cost of time-tracking software includes a worksheet for comparing seat price with operating cost.

13. Who performs migration, what moves, and how will we validate it?

I used to treat migration as an implementation detail. That is backwards; migration is the first production test of the vendor.

List the objects that must move: people, teams, clients, projects, assignments, tags, time entries, notes, approval states, edit history, attachments, pay rates, and billing rates. Not every source system will expose all of them, so ask the vendor to mark what is available, transformed, omitted, or recreated.

Run a sample before cutover. Reconcile record counts and total hours by period, inspect a few edited and approved records, and agree who signs off. Also ask how failed rows are returned and whether the old system remains read-only during the validation window.

“Send us a CSV” is an input method, not a migration plan. The plan needs a human owner, scope, validation, rollback decision, and date.

14. Which features are live, which are supported, and which are only planned?

Build three columns during the demo: live now, available with conditions, and roadmap. Put every answer in one. If a feature requires a beta flag, enterprise plan, separate app, particular device, custom service, or future release, record that condition.

Ask the vendor to open the current product and show the feature from an ordinary customer account. Then confirm the support policy, response route, operating hours, escalation path, status page, release notes, and service commitments in writing.

Roadmaps change. Score a planned feature as unavailable and decide whether the product still passes. “Coming soon” may be honest, but it cannot close today's workflow gap.

15. What happens to our records, settings, and contract if we leave?

Request a sample complete export before signing. Check whether it contains raw time entries, users, projects, notes, approvals, edits, screenshots or their references, activity data, and audit events. Ask whether the export covers the whole organization or only what the requesting user is allowed to see.

Toggl Track's export documentation is a useful reminder that export scope can depend on access level and workspace selection. Again, that is not a criticism. It is the detail hidden inside the word export.

Confirm format, API access, export charges, request time, notice period, automatic renewal, post-termination access, backup deletion, and whether the vendor provides deletion confirmation. Open the sample files. A proprietary archive that only the old vendor can read is not portability.

If the product still passes after you imagine leaving it, the relationship is less likely to become a trap.

When not to buy time-tracking software

Do not buy yet if the team cannot name the decision, the review owner, or the correction policy. Software will make an unclear rule faster and more visible. It will not make it fair.

A separate system may also be unnecessary when one owner reviews a very small team's straightforward hours and the existing record already satisfies payroll, billing, and legal needs. Keep the process that works until the cost of missed information exceeds the cost of another system.

Delay the purchase when a vendor will not show edge cases, provide security terms, explain employee access, separate live features from roadmap items, or produce a usable exit file. Those are not post-sale details. They are the purchase.

How Kordano answers the questions it can answer today

Kordano Time is in Early Access, with access planned to begin on December 1, 2026. Some product behavior is still being built, so we will not present a roadmap item as a confirmed feature.

Here are the commercial and product facts confirmed today:

• The Founding 100 price is $3 per person per month for teams of 6 or more
• Billing is month to month, with no yearly contract required
• The $3 price is locked for 24 months
• After 24 months, Founding members pay $4 per person per month, reflecting a permanent 20 percent discount from the $5 public price
• Teams with fewer than 6 people receive $4-per-person Early Access pricing and do not receive a Founding spot
• The offer is limited to 100 qualifying companies, not 100 individual people, and it will not reopen after those spots are taken
• After the 100 spots are taken, new customers will pay the public price of $5 per person per month
• Migration for Founding 100 customers is free, unlimited, human-assisted, and available from any product
• Migration can use a CSV export or secure access and can include projects, users, work history, and other available information that can be moved
• GPS, geofencing, and employee-location tracking are not currently confirmed features. Kordano may consider them in the future depending on customer demand

Those answers should be held to the same standard as every other vendor's. Check the current terms on the Kordano Time pricing page, ask us to show what is live, and mark anything else Needs proof.

Fifteen questions will not make a buying decision automatic. They will make the assumptions visible. That is the point.

Use the same scenarios. Keep the evidence beside the score. Reject the answer that disappears when the demo gets messy.

If Kordano fits your team, join the Founding 100.