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:

• Workers, Hours and Gross pay: the exact totals that will be written.
• The movement against the last finalised week, for example “+4.2% vs last finalised week ($12,340.50).” or, with no prior run to compare, “No prior finalised week to compare against.”
• An amber warnings 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 day(s).”).

Select Finalise week in the dialog (it reads “Finalising…” while it saves). Nothing to fix is mandatory: the warnings are informational, not blockers. Finalise week itself is only disabled when the page is still loading, when there are no rows to finalise, or while a finalise is already in flight.

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 button is replaced by a green Finalised [date] badge and a Reopen button next to it.

Once finalised, a Record payment button appears next to the badge. Select it to open Record this week as paid?, warning “Marks the finalised run as paid with today’s date and your user. This is the as-paid audit record; it does not move money.” Optionally enter a Payment reference (optional) (placeholder “Bank batch id, ABA file, remittance note”) and select Record payment (it reads “Recording…” while it saves).

Once recorded, the Record payment button is replaced by a green Paid [date] badge (hover it to see the reference, if you entered one) and an Unmark paid button appears alongside it.

Select Unmark paid to open Clear the paid state?, warning “Removes the paid date, user, and reference from this finalised run.” Confirm Unmark paid and the week drops back to its finalised-but-unpaid state, with Record payment available again.

Select Reopen to open Reopen this finalised week?. The warning changes depending on whether the week is marked paid:

• Not paid: “The saved snapshot is discarded and the week recalculates from current shifts and rates.”
• Paid: “This week is recorded as PAID. Reopening discards the snapshot AND the payment record, and the week recalculates from current shifts and rates.”

Confirm Reopen (it reads “Reopening…” while it runs). The week immediately reverts to a live computation from current shifts, classifications 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.