Offline Time Tracking Software: 9 Sync Tests

At 5:42 p.m., an employee's phone records a clock-out without a connection. At 6:05, a supervisor sees an open shift in the web dashboard and repairs it. At 6:17, the phone reconnects.

The shift now has two plausible endings.

This is a hypothetical failure scenario, not a customer story. It exposes the question that matters when evaluating offline time tracking software: does the system merely upload later, or can payroll see what happened when the uploaded event collides with work already done online?

U.S. Department of Labor recordkeeping guidance allows employers to choose a timekeeping method as long as the resulting records are complete and accurate. That standard is useful well beyond U.S. compliance: an offline badge is irrelevant if the final record cannot be explained. The vendor and authority documentation in this guide was checked on August 25, 2026. This is a desk review, not a hands-on product test or legal or payroll advice.

The short answer

An offline time clock should pass nine tests before payroll depends on it:

1. Pending state: every offline event remains visibly pending until the server accepts it.
2. Context: project, client, pay code, break type, notes, and required fields survive the offline period.
3. Clock integrity: the record preserves event time, receive time, device time zone, and any clock correction.
4. Duplicate and overlap handling: the system detects two events that describe the same work period and shows which one won.
5. Parallel edits: a phone edit, web repair, and second-device change resolve by a written policy.
6. Correction history: manual repair keeps the original value, new value, actor, time, and reason.
7. Approval impact: a late synced event reopens or rechecks any approval it materially changes.
8. Payroll version: the export identifies which approved record version it contains and reconciles to a control total.
9. Recovery: pending records survive an app restart, operating-system interruption, safe logout flow, and documented device recovery path.

Fail any test that silently drops an event, changes payable time without a new decision, or leaves payroll unable to match the export to the approved source.

The buying target: a receipt, not a promise.

For a broader procurement review, use these tests beside the 15-question time-tracking software scorecard. The scorecard asks whether offline support exists. This guide tests what that answer means.

Offline is six promises, not one feature

Across current help pages, offline describes several different product states rather than one standard capability.

Toggl Track's offline documentation shows a visible warning on unsynced entries and limits offline use to time tracking rather than reports, project management, or settings. Clockify's Windows documentation says local entries sync later, but projects, tasks, and tags are unavailable offline. It also warns that logging out before sync loses the pending data.

Other products draw the boundary elsewhere. Connecteam says its standard mobile, kiosk, desktop, and NFC clock surfaces require a connection; its documented offline exception is a custom physical-clock integration through the API. TimeCamp says its kiosk requires a connection and lets people enter hours retroactively after an outage. Retroactive reconstruction may be a valid fallback, but it is not the same record as an event captured at the moment of work.

The useful detail in current offline documentation is rarely the promise that entries sync later. It is the list of data and actions that disappear while the device waits.

Android's current offline-first architecture guidance treats local storage, queued writes, synchronization, versioning, and conflict resolution as separate design choices. That engineering distinction gives buyers a practical rule: do not accept one successful airplane-mode timer as proof of all six promises.

Tests 1 to 3: prove the device record

1. Make pending state visible

Create a clock-in, break, note, edit, and clock-out while disconnected. Every item should display a local identifier and an unambiguous pending state. Reconnect, then require a success state tied to a server record.

The system should show at least three moments: when the worker acted, when the device queued the action, and when the server accepted it. A spinning icon is not a receipt. Payroll needs to distinguish “captured on device” from “accepted into the company record.”

2. Take the full work context offline

Before disconnecting, assign a new project, archive an old code, and change one required field. Then go offline and record time.

The goal is not to demand every screen without a connection. It is to learn which reference data is cached, how old it may be, and what happens when a queued record uses a code that changed online. If the product permits time without required context, the record should remain an exception rather than quietly inheriting a default.

This matters because an accurate duration can still reach the wrong client, department, cost center, or earning code. The BPO time-tracking evidence chain applies the same principle to planned shifts, captured time, approval, client billing, and service results.

3. Separate event time from device time

Record one event, change the device time zone, move the device clock forward, and record another. Restore the correct settings before reconnecting.

A pass keeps the raw event time, device time zone or offset, server receive time, and any normalized company time. It also flags an impossible sequence instead of manufacturing a clean shift from a bad clock. The policy for device-clock anomalies should be written and visible to reviewers.

Tests 4 to 6: force a collision

The decisive operating pattern begins when a second actor changes the same shift before the first device reconnects.

4. Create a duplicate and an overlap

While the phone is offline, create a second online clock-out for the same shift. Then add an overlapping manual entry. Reconnect the phone.

VeriClock's current documentation makes its policy explicit: the offline event is treated as the conflict, automatically deleted in favor of the online event, and available for restoration after the overlap is removed. Deltek Costpoint exposes different choices for conflicting timesheet cells: use the offline hours, use the online hours, or combine them, with a revision explanation.

VeriClock makes its conflict winner explicit, while Deltek exposes three different choices. That contrast is more useful than a generic offline badge. Neither example establishes a universal winner. The vendor must state whether it rejects, replaces, combines, queues for review, or preserves both values. A conflict that is resolved invisibly is still unresolved for the person who must defend payroll.

5. Edit the same shift from two places

Change the project on the offline phone. Change the stop time in the web dashboard. If the product supports another device, add a note there too. Then restore the connection.

The pass condition is deterministic and field-aware. Changes to different fields may coexist. Competing values for the same field need one declared winner or a review queue. “Last write wins” is only meaningful if the product defines which timestamp counts and protects the history from a wrong device clock.

6. Repair the record before reconnecting

Run the opening scenario exactly. The supervisor repairs the apparently open shift while the worker's phone still holds the real stop. Require the final history to show both events and the rule or human decision that selected the payable result.

The common checklist mistake is treating automatic sync as the end of the test instead of the start of reconciliation. The repair path is where actor, reason, before-and-after values, and notification become essential. The worker should be able to see and challenge a correction that affects pay, a principle covered in who controls workforce data.

Tests 7 to 9: follow the event into payroll

7. Sync after approval

Approve the timesheet while the device is offline, then reconnect with an event that changes payable time or coding.

A pass follows the company's policy and makes it visible. The system may reopen the sheet, revoke the approval, or create a blocking exception. It should not leave the old approval attached to a materially different record. Require a notification to the approver and a queue that payroll can clear before cutoff.

8. Export before and after the late sync

Export the approved period once while the event is pending. Reconnect, resolve the conflict, approve the new version, and export again.

Each file should have an export identifier, period, created time, record count, total hours, and source version. The second export should reconcile to the revised approved total. If the payroll integration pushes directly, require the equivalent batch receipt, retry history, and duplicate-prevention key.

9. Interrupt the device safely

With several unsynced events queued, force-close and reopen the app, restart the device, and follow the vendor's supported logout and recovery procedure. Ask what an administrator can see while the device remains missing.

One line in Clockify's documentation changes this test: logging out can erase entries that have not synced. The point is not to single out one product. It is to turn every vendor's documented recovery boundary into a trial step. App reinstall, device replacement, local database damage, and account removal need written outcomes before a field team depends on local storage.

Use the Offline-to-Payroll Failure Matrix

Run all nine tests against one sample worker and one sample pay period. Record the expected result before the trial so a polished demo cannot redefine success after the fact.

CMiC's current offline documentation offers a useful model for visibility: device sync status, a synchronization log, failed-sync indicators, and explicit retry, discard, rename, or merge actions. The exact controls vary by product, but the purchasing standard should stay fixed: every unresolved record has an owner and a next action.

Require a twelve-field Sync Receipt

The trial should produce one compact artifact for every offline event batch. This Sync Receipt is a Kordano evaluation framework, not an industry standard.

The receipt does not need to be one literal screen. It can be assembled from an event log, exception queue, approval history, and export log. The requirement is that an operations or payroll lead can trace the path without asking engineering to reconstruct a database history.

Run the trial in 45 focused minutes

Use a trial tenant, two user accounts, one phone, one browser, and the exact export format payroll expects.

1. Minutes 0 to 10: create the worker, codes, schedule, and pay period. Record the clean expected total.
2. Minutes 10 to 20: disconnect the phone and create starts, stops, a break, a note, and a context change.
3. Minutes 20 to 30: make conflicting web edits, approve the sheet, and create the first export.
4. Minutes 30 to 40: reconnect, resolve every exception, approve the changed version, and export again.
5. Minutes 40 to 45: reconcile record counts and total hours, then capture the Sync Receipt.

Pass only when every queued action has a final state, every conflict has a visible reason, approval attaches to the final payable version, and the export reconciles. A vendor may need more time to configure the trial, but the failure path itself should be simple enough for payroll and operations to understand.

Where KordanoTime fits

KordanoTime opens access December 1, 2026. The first release captures online and offline time and carries it through daily timelines, schedules, attendance, breaks, leave, approvals, and payroll-ready integrations or exports. Teams set the review and approval policy; the record keeps capture, correction, decision, and handoff distinct.

Early Access includes 500 screenshots per company each month, while the Team tier includes unlimited screenshots. Screenshot and video evidence uses company-owned Amazon S3 or Cloudflare R2 storage, keeping the media account under the company's control.

GPS, geofencing, and employee location move into the planned 2027 release. They are outside the first-release scope, so an offline time test for December should evaluate time, work context, review, approval, and payroll handoff without treating location as available evidence.

See how KordanoTime carries work records from capture to review.

The decision rule

Do not buy offline time tracking software because a timer kept running in airplane mode. Buy it only when the company can explain the final payable record after the worker, supervisor, approver, and payroll export have all acted at different times.

The strongest answer is not “syncs automatically.” It is a completed Sync Receipt with no unresolved records, an approval tied to the final version, and a payroll batch that reconciles.

Frequently asked questions

Can time tracking software work without internet?

Some products store starts, stops, breaks, or edits locally and send them when a connection returns. The supported actions differ by product and device surface, so test the exact mobile app, desktop app, browser, kiosk, or physical clock the team will use.

What happens to offline time entries when the connection returns?

The device sends queued events to the server, where they may be accepted, rejected, merged, replaced, or held for review. A payroll-safe product shows the pending state, the final result, and any conflict with an online edit.

Can offline time tracking create duplicate payroll entries?

Yes, if an offline event and an online repair both describe the same shift and the product or integration lacks duplicate controls. The system should link both inputs, apply a declared conflict rule, and export only the approved canonical version.

How should payroll verify synced offline time?

Reconcile the number and total duration of pending, accepted, conflicted, approved, and exported records for the pay period. Keep a Sync Receipt or equivalent audit trail that connects each local event to its final approval version and payroll batch.