Designing payroll month close as a state machine

Monthly payroll is often presented as a calculation screen. In practice, the dangerous part is not arithmetic; it is ambiguity about whether the inputs are complete, reviewed, and safe to treat as historical fact.

Store Payroll Assistant models that ambiguity through explicit states.

Estimated is useful, but provisional

An estimated amount helps an operator see progress while attendance or adjustments are incomplete. It should remain visibly provisional. Exports made before close are marked as drafts so a useful preview cannot be mistaken for a final record.

Confirmed means a human completed the input

Confirmation is not inferred from a non-zero number. Each employee’s payroll input must be valid and deliberately confirmed. Missing, invalid, or unconfirmed items block the store from closing.

This makes readiness computable. An all-store view can identify the exact work preventing close instead of asking an operator to remember which records still need attention.

Closed creates a historical boundary

Closing a store-month freezes a snapshot. Later employee transfers or store changes should not rewrite that record. If a correction is necessary, unlocking requires a reason so the transition remains visible rather than silently mutating history.

The simplified flow is:

estimated → confirmed → closed → unlocked with reason → confirmed → closed

Each arrow is a product action with a precondition. The state model therefore drives interface copy, validation, exports, audit behavior, and test cases at the same time.

What the model does not solve

A state machine cannot make an input correct, replace review, or turn demonstration software into a payroll authority. It can prevent incomplete work from looking finished and make consequential transitions understandable.

That is the standard I want for operational tools: the interface should reveal uncertainty before it offers finality.