Skip to content

Timesheets — Workflow

Overview

A collaborator submits a timesheet recording the hours worked on a project or department during a calendar week. A supervisor or HR reviewer approves or rejects it. Approved hours feed into billing (Freshbooks), accounting reports, and attendance PDFs. Timesheets sourced from the Kimai integration follow a parallel path and are auto-approved or processed in bulk.

Note

This feature follows SARA's standard record lifecycle model. See: Workflows & Pipelines

Roles involved

  • Collaborator — Captures working hours via Timesheets Capture. Saves drafts and submits for review. Receives rejection notifications and resubmits when needed.
  • Supervisor / HR reviewer — Reviews submitted timesheets via the main Timesheets screen. Approves or rejects each timesheet with a reason.
  • Kimai system — External time-tracking integration. Imports timesheets automatically and can bulk-approve them.

Status lifecycle

  • INPG — In progress. The collaborator has saved a draft but not yet submitted it for review. Only visible in Timesheets Capture.
  • PEND — Pending review. The collaborator submitted the timesheet; it is waiting for a reviewer decision. Visible in the Reviewing tab of the main Timesheets screen.
  • REJC — Rejected. The reviewer rejected the timesheet with a reason. The collaborator can view the reason in Timesheets Capture and resubmit.
  • APPR — Approved. The timesheet is accepted. Approved hours are available across Search, Accounting, and Report tabs. Kimai-imported timesheets are marked APPR at import.

Info

For system-wide status guidance, see: Status

Workflow

Workflow steps

  1. Collaborator creates a timesheet and enters daily hours (project or department, work type, total and billable hours).
  2. Collaborator saves as a draft (INPG) or submits for review (PEND).
  3. Supervisor or HR opens the Reviewing tab, inspects the week detail, and approves or rejects.
  4. Approval → status becomes APPR; billable hours sync to Freshbooks if the integration is active.
  5. Rejection → status becomes REJC; collaborator receives an email with the reason and can resubmit.

Capture

The collaborator opens Timesheets Capture and finds the relevant project or department in the accordion. Clicking + New timesheet opens the two-stage entry modal:

  • Stage 1 — Select the date (week number shown in the calendar picker), choose type (Project or Department), select the project with its work item or the department.
  • Stage 2 — Enter one row per day: work type (Work on-site, Work offline, Day off (on-site), Training, or Travel), total hours, and whether hours are billable (YES toggle). Additional rows can be added for the same day. Select the plant or facility where the work took place — plant is required for all types except Work offline, which hides the plant selector. When Day off (on-site) is selected, hours are automatically set to zero. Attach supporting files and add an optional comment.

The collaborator can:

  • Click Save timesheet to store the entries as a draft (INPG) and return later to complete them.
  • Click Submit to finalize and send the timesheet to the review queue (PEND).

An INPG timesheet remains editable in Timesheets Capture. A PEND timesheet is locked awaiting review.

Review

The supervisor or HR reviewer opens the Reviewing tab on the main Timesheets screen. The table lists all PEND timesheets. The reviewer opens the week detail view to inspect each day's entries — work type, project, total hours, and billable hours.

From the detail view the reviewer either:

  • Approves the timesheet. Status changes to APPR. If the Freshbooks integration is active, all hours marked as billable are synced to Freshbooks as time entries at this moment.
  • Rejects the timesheet. The reviewer selects a rejection reason from the catalog and can add a comment. Status changes to REJC. An email notification is sent automatically to the collaborator.

Once approved or rejected, the timesheet no longer appears in the Reviewing tab.

Resubmission

The collaborator sees REJC timesheets in Timesheets Capture alongside the rejection reason and comment. The collaborator edits the timesheet and resubmits it. The status returns to PEND and the review cycle repeats.

Notifications

  • Rejection email — Sent automatically to the collaborator's work email when a timesheet is rejected. Includes the year, week, project, rejection reason, and reviewer comment.

Note

For global notification behavior, see: Notifications & Alerts

Setup & dependencies

  • Project catalog — Projects must exist and be active for the project selector in the entry modal to be populated.
  • Logistics calendar — CSV imports are validated against project logistics calendar events. Days outside the calendar are rejected.
  • Project minimum hours — If a project defines a minimum weekly hour requirement, the entry modal displays an informational banner before the collaborator begins entering hours.
  • Freshbooks integration — Must be configured and active (FRESHBOOKS=1) for billable hour sync to occur on approval. If not connected, approval without Freshbooks sync is still possible; if connected but the project or collaborator is not linked in Freshbooks, approval is blocked until the link is established.
  • Kimai integration — Must be configured and active (KIMAI=1) for the Kimai tab and Kimai section in Capture to appear. Projects and collaborators must be linked to their Kimai counterparts via their respective records.

Exceptions & operational notes

Kimai import path — When the Kimai integration is active, timesheets are imported automatically from the Kimai time-tracking system (physical card-reader nodes). These timesheets bypass the collaborator-entry step and arrive in SARA as APPR (auto-approved) or as records ready for bulk approval. The supervisor can bulk-approve all pending Kimai timesheets from the Kimai tab with a single action.

Freshbooks validation on approval — When Freshbooks is active, approval checks that:

  • The Freshbooks connection is valid.
  • The project is linked to a Freshbooks project.
  • The collaborator is linked to a Freshbooks staff record.

If any check fails, the approval is blocked and the reviewer receives an error message explaining the missing link.

Rejection of Freshbooks-synced timesheets — If a timesheet has already been synced to Freshbooks (billable hours billed), it cannot be rejected. The reviewer must first remove the Freshbooks entries manually before the rejection can proceed.

Per diem calculation — Per diem is calculated per day entry using a two-layer priority rule:

  • Layer 1 — Confirmed logistics plan (PL) takes priority. If the collaborator has a confirmed PL covering that project and date, the PL's if_perdiem flag determines the result. If any confirmed PL for that collaborator + project + date has per diem enabled, the day generates per diem. Only if all confirmed PLs for that day have per diem disabled is it suppressed. The collaborator's selected hour type does not override the PM's confirmed plan.

  • Layer 2 — Fallback (no confirmed PL). When no confirmed PL exists for the day, per diem is determined by the hour type and plant city:

Hour type Condition Per diem
Work on-site Plant city ≠ collaborator's home city Yes
Work on-site Plant city = collaborator's home city No
Work offline — (no plant recorded) No
Training Plant city ≠ collaborator's home city Yes
Training Plant city = collaborator's home city No
Travel Any Yes
Day off (on-site) Plant city ≠ collaborator's home city Yes
Day off (on-site) Plant city = collaborator's home city No

Note

The logistics plan if_perdiem flag is set by the PM at the time of PL creation or edit. It defaults to enabled, preserving historical behavior for all existing PLs.

Per diem source indicator in HR approval — The week detail view shown to reviewers includes a per diem source indicator on each day row: whether the charge comes from a confirmed PL or from the fallback city comparison. Day rows with no plant recorded where a plant is expected show a warning indicator; approval is not blocked.

Permissions

Permissions

Access and actions are permission-driven. See: Permissions