Time and Attendance Tracking Software: Exception Spec Template

Choose software that carries actual worked time through approval

A clock records an event. Your operating process still needs to establish what happened when someone misses a punch, changes sites or disputes a correction. An alert is useful only if someone can act on it.

ADP’s timekeeping software guide identifies time capture, attendance information, reporting and payroll integration as evaluation areas. Treat those as starting points for questions, not proof that every product handles your exceptions.

Use this reusable time and attendance exception specification to turn those questions into acceptance criteria. Copy one record for each situation you need a vendor to demonstrate.

Field	Your entry
Operating situation	What happened to the time record?
Expected record	What must the resolved record contain?
Responsible owner	Who confirms that resolution is acceptable?
Vendor question	What must the vendor demonstrate?
Acceptance criterion	What observable result counts as passing?
Observed evidence	Not tested until demonstrated
Unresolved dependency	Missing requirement, assigned owner and next action
Review date	When will the owner check it again?

The specification evaluates time capture through approved delivery. It does not establish that the software processes payroll, handles taxes or meets every legal requirement.

Require managers to reconcile scheduled time with actual work

A scheduled finish is a plan, not evidence that work ended then. A missing clock out leaves a question that the worker and manager must resolve. Automatically inserting the scheduled finish can hide that question rather than answer it.

An early punch also needs context. Department of Labor guidance on clock records distinguishes voluntary early presence without work from actual working time. That distinction does not permit a manager to ignore work performed before the scheduled start.

Ask vendors to show scheduled and recorded time together. Then ask how the manager investigates the difference, what access permits a correction and what remains visible after saving it. These are purchase requirements, not capabilities to assume.

Purchasing software does not itself guarantee compliance. The federal recordkeeping guidance concerns the accuracy of the resulting records, regardless of the method selected. Keep that distinction clear when a demonstration shifts from showing a feature to making a compliance promise.

Copy this exception specification into your vendor evaluation

Build the evaluation from recent timecards, with personal information removed. Choose situations that create actual work for your managers and payroll team. A demonstration built only around complete punches tells you little about correction handling.

Use the same specification for every vendor. The starter entries below define proposed requirements, not verified product behavior.

Operating situation	Expected record	Responsible owner	Vendor question	Acceptance criterion	Observed evidence	Unresolved dependency	Review date
Missing clock out	Confirmed actual finish and reviewed correction	Shift manager	How does the worker confirm the finish and the manager review it?	Save a confirmed correction and show treatment of the original record	Not tested	Shift manager: confirm worker response route; payroll: confirm correction handling	Set before demonstration
Site transfer	Actual work retains the correct site context	Operations	How does time remain assigned to the correct site after a transfer?	Show site context in the saved record and required payroll output	Not tested	Operations: define site mapping; payroll: approve output fields	Set before demonstration
Change after approval	Corrected record with an accountable approval state	Payroll	Who can reopen the record, and what happens if payroll already received it?	Demonstrate permitted access, saved changes and downstream correction responsibility	Not tested	Payroll: confirm receiving system procedure and cutoff	Set before demonstration
Clock access failure	Actual work recorded through an agreed fallback	Operations with IT	What happens when a worker cannot use the clock?	Demonstrate fallback entry, recovery and duplicate checks	Not tested	IT: validate access conditions; operations: approve fallback procedure	Set before demonstration

Assign a named person in your organization to each owner field before testing. A department label helps route the work, but someone needs authority to accept evidence or leave the requirement unresolved.

Run the specification in this order:

1. Operations selects the situations. Include the clock methods, locations and worker access conditions that apply to your team.
2. Payroll defines the required output. Identify the receiving system, required fields and what makes a record unacceptable.
3. The vendor demonstrates the action. Ask to see the permitted user role, the saved result and the exception path when the normal route fails.
4. The owner records the evidence. Add the demonstration date, relevant documentation and any remaining dependency. Keep an unproven requirement marked Not tested.

A verbal answer is not the same as demonstrated behavior. If configuration or another system is required, record who supplies it and when it will be tested.

Fill the first entry with a missing warehouse clock out

Hypothetical example: A warehouse shift is scheduled from 7:00 a.m. to 3:30 p.m. The timecard contains a recorded start but no finish. Assume the actual finish has not yet been confirmed, so both the finish time and hours worked remain unknown.

Here is the first specification entry with the operating requirements filled in. The evidence field intentionally remains Not tested.

Field	Hypothetical entry
Operating situation	Missing clock out on a warehouse shift scheduled from 7:00 a.m. to 3:30 p.m.
Expected record	Confirmed actual finish time and reviewed correction
Responsible owner	Shift manager
Vendor question	How does the worker confirm the finish time and how does the manager review it?
Acceptance criterion	Demonstrate confirmation and review without silently substituting the scheduled finish; show the saved correction and treatment of the original record
Observed evidence	Not tested
Unresolved dependency	Shift manager to confirm the worker confirmation route; payroll to confirm correction handling
Review date	Before the next evaluation session

The manager needs a route to establish when work actually ended. The vendor should show how that information reaches someone authorized to review it, what gets saved and whether the record is ready for the next approval step.

The DOL’s distinction between clock records and actual work supports investigating the discrepancy. It does not support treating 3:30 p.m. as the actual finish simply because that was the schedule.

If the worker cannot respond before cutoff, ask the vendor to demonstrate the unresolved state. Your payroll owner must define how that situation is handled. A disappearing alert is not proof that the underlying record became accurate.

Test access failures and reopened timecards before trusting the export

The other entries expose problems that a clean timecard demonstration can miss. ADP’s evaluation guidance includes accessibility, integrations and offline punching as considerations for relevant environments. That makes them questions to investigate, not capabilities to assign to every vendor.

Clock access must match the worker’s conditions

Ask what happens when a worker cannot use the proposed clock method. Test the conditions your team actually faces, whether that is a shared device, unreliable connectivity or an account access problem.

Have the vendor identify the fallback, who can use it and what information it preserves. Then inspect recovery: can someone tell whether the same work was entered twice? If offline capture is required, leave that dependency open until the supported behavior is documented and demonstrated.

Site changes must survive the handoff

A worker transferring between locations can leave payroll with hours that lack usable site context. Ask operations to define the expected attribution before the demonstration begins.

Follow the record through correction and output. Confirm whether the receiving system gets the site information it needs, rather than assuming that a site visible on screen will also appear in the export.

Approval must have a defined correction route

Ask who can change an approved timecard and what access that person needs. Require the vendor to show what happens to the approval state, the saved change and the original information.

Then move the test past payroll delivery. Identify who owns the correction when the receiving system already has the earlier record. Do not assume another export will update it correctly or prevent duplicate entries.

Before accepting the handoff, payroll should obtain specific answers about:

• The supported payroll destination and any configuration dependencies.
• The fields transferred and how rejected records become visible.
• The person responsible for downstream corrections and reconciliation.

These answers belong in the existing specification. They should not sit in a separate email thread that the approval owner never sees.

Evaluate Teambridge’s time review alongside your exception requirements

Teambridge brings scheduling, time tracking and timesheets into an all in one platform for hourly teams, tailored to each company. For this evaluation, the relevant question is how its time review fits the situations in your specification.

The Teambridge time tracking page describes reviewing scheduled and recorded time together, with worker, site, role and history visible. It also describes surfacing exceptions before payroll review. That documented review context maps to investigating a missing punch or a site discrepancy.

The broader Teambridge platform describes shared operational records and configurable workflows. Use the demonstration to establish how your managers would work within that setup, rather than treating the platform description as proof of every correction path.

Request implementation documentation for the relevant access requirements, saved correction state and treatment of original records. The cited product pages do not establish the complete procedure for those details or for corrections after payroll delivery.

Keep the product boundary explicit. Time tracking and timecard review do not, by themselves, establish offline capture, universal payroll connector coverage or tax processing. Evaluate any required capability separately and leave it unresolved until supported.

Keep the specification current with each pay cycle

During evaluation and any pilot, update the same artifact rather than starting another checklist. Attach the pay period, population and local acceptance threshold to each review so the results have a consistent meaning.

Operations should count unresolved exceptions at cutoff. Payroll should count records requiring manual repair, using an agreed definition of repair so ordinary review does not get mixed into the total. Report each count alongside the number of timecards reviewed.

Managers should record correction elapsed time from exception identification to approved resolution. Report its median for resolved exceptions in the review period, and keep unresolved cases visible separately. Otherwise, the oldest open problems can disappear from the timing measure.

Track timecards changed after approval separately, including whether the change happened before or after delivery to payroll. These are proposed operating measures, not industry benchmarks. Set acceptable thresholds before the pilot based on your cutoff and available review capacity.

Update owners, evidence and review dates whenever clock access, work rules, sites or payroll destinations change. A previously accepted correction path may need another demonstration after a material change.

Bring the specification to the next vendor demonstration. For every critical requirement, ask for a demonstrated result or an explicit unresolved dependency with an owner and review date. That gives you a purchasing decision grounded in how your team will resolve time records, not just how workers will punch in.