A period is the bucket a time entry falls into by its work date: a calendar month or a Monday-based week, in the workspace's time zone. Closing a period is how SAQ locks time. There is no submit-and-approve workflow for timesheets; the close is the approval, and a closed period is what a billing run reads.
How it relates to other concepts
- Periods are created on demand as time is logged, and any calendar gaps are filled so that closing stays contiguous.
- After the close, changes to work facts go through corrections in an open period.
- Reports can show a period "as of period close" because the close snapshots every entry's facts.
- A recurring time bank is credited per period at the billing run.
Rules
- Period length (month or week) is a workspace setting. Changing it before any close re-buckets existing entries; after the first close it is locked, and so is the workspace time zone.
- Periods close in order: the earliest open period first.
- The first close fixes the first period start. It must be a calendar boundary and cannot exclude time that is already logged. After that, nobody can log time before it.
- Closing is done by an Owner or Admin in the browser, with a recent re-authentication and a typed confirmation (the period's start date). It is not available to API tokens.
- Closing is irreversible. A period can never be reopened.
- The pre-close checklist is advisory and never blocks: people below their weekly target, tickets moved or re-attributed after time was logged, older billable work in progress on open deliverables, open deliverables that resolve to a time bank, and entries without an applicable rate.
- Closed cells in the weekly grid read "Period closed on {date} by {person}".
Example
On 1 October an Admin opens Billing → Periods, reviews the checklist for September, re-authenticates, types 2026-09-01, and closes it. October's entries continue as normal; a forgotten September hour is added as a correction dated today.