Finalise a week and record payment

In the week navigation row, select Finalise week (top right). A confirm dialog titled Finalise this week? opens, warning “Freezes this week into the immutable pay record. Finalised weeks are no longer re-priced by rate or shift changes. You can reopen the week later if something needs to change.”

Above the Cancel / Finalise week buttons it shows what you are about to commit, as a small table with the columns Week, Workers, Hours and Gross pay. The first row is This week with the exact totals that will be written. When you have finalised a week before, a second row, Last finalised, carries that week’s gross for comparison.

Underneath sits the movement against that last run, for example “+4.2% vs last finalised week.” or, with no prior run to compare, “No prior finalised week to compare against.” Then an amber list of everything this run leaves out, drawn straight from the checklist: unreviewed shifts and their hours (“N clocked shift(s) (Xh across Y worker(s)) are awaiting review and will NOT be paid in this run. Approve them in Scheduling first if they belong in this week.”), unclassified workers (“N worker(s) [is/are] unclassified and will be recorded at $0 gross.”), and unseeded public holidays (“N public holiday(s) this week [is/are] not seeded and will be priced as ordinary days.”).

Select Finalise week in the dialog (it reads “Finalising…” while it saves). The pre-flight warnings about unreviewed hours, unclassified workers and missing holidays are informational. Separate data and assessment checks can block finalisation. Resolve pending vehicle-allowance assessments, changed broken-shift assessments, invalid pay rates and incomplete or changed payroll sources before continuing. Finalise week is also disabled while loading, when there are no rows, or while another finalise is running.

Once it succeeds, the grid switches from live-computed to reading the frozen snapshot: rate changes and shift edits made afterward no longer affect this week’s figures. The Finalise pill in the checklist relabels itself Finalised on DD/MM/YYYY, and a Reopen button replaces the finalise button in the week navigation row.

Payment is recorded per worker, from the Sync & pay column at the right of the weekly grid. Select the banknote icon on a worker’s row (it stays disabled until the week is finalised, with the tooltip “Finalise the week first”) to open the drawer Pay [worker name]: “Record this worker as paid for the finalised week. Add a payment reference and attach the bank batch report or remittance advice.”

Select Mark as paid. The worker’s banknote turns green and hovers as “Paid on DD/MM/YYYY. Ref: …”. Reopening the drawer afterwards shows a Paid on DD/MM/YYYY banner with the reminder “This is the as-paid audit record; it does not move money.”, the reference locked, and the submit button changed to Upload evidence so you can still add files. An Unmark paid button sits beside it if you recorded the wrong worker.

Select Reopen to open Reopen this finalised week?, warning “The saved snapshot is discarded and the week recalculates from current shifts and rates. Any recorded worker payments for this week are discarded with it.”

Confirm Reopen (it reads “Reopening…” while it runs). The week immediately reverts to a live computation from current shifts, applicable dated worker pay settings and rates, exactly as it was before it was ever finalised, so anything you fix afterward (approving a late shift, correcting a classification) is reflected the next time you finalise.