Between "the numbers look right" and "the numbers are in the ledger" sits a sign-off. Payroll runs are wired into the platform's approval engine with a seeded process, and the connection runs deeper than a status stamp: a payroll run's final approval posts the accrual to the ledger automatically, so approving is not an opinion about the run — it is the act that commits it.
The seeded process
xMatix ships an approval process for payroll runs so the gate exists on day one:
| Setting | Seeded behavior |
|---|---|
| Entry condition | Runs in Draft qualify |
| Submission | Auto-submit — a qualifying run enters the process without a separate submit click, and its status shows pending approval |
| Steps | One approval step, resolving a specific user as approver |
| Recall | The submitter may recall their own pending request |
| Notifications | Sent on submission, approval, rejection and revert |
Treat the seeded process as scaffolding: the step's approver must be pointed at your payroll approver, and you can reshape it freely in the approval designer — more steps, team or role approvers, entry conditions on amount, timeouts. Everything on the approval processes page applies; approvers can act from the web inbox or on mobile.
What each decision does to the run
The approval outcome is mirrored onto the run itself, so the run's own status always tells the truth without opening the approval record:
| Decision | Effect on the run |
|---|---|
| Approved | Approval status Approved; the run is marked Approved and the accrual posts to the ledger — journal, statutory payables, per-employee net-pay open items — landing the run in Posted |
| Rejected | Approval status Rejected; the run returns to Review for correction and recalculation |
| Recalled | The approval status clears; the run returns to Draft |
| Reverted (sent back a step) | Approval status back to Pending; the run sits in Review while the earlier step re-decides |
The bridge is idempotent and safe against the one race that matters: a run that is already posted is never posted again by an approval decision, and a rejection or recall arriving after posting does not un-post the ledger — the posted state wins, because the ledger is the record.
When approval succeeds but posting fails
The approval decision and the ledger posting are two acts, and the platform refuses to let a posting problem corrupt the approval record: if posting fails on final approval — a component missing its GL mapping, no Payroll Payable control configured — the approval stands, the failure is logged, and the run remains approved but unposted. The fix is ordinary: resolve the named configuration gap and run Post on the run directly. This is also why the run's own Post action exists alongside the approval path — the same posting, reachable by hand.
Common questions
Can we run payroll without the approval gate?
The posting action works directly on a calculated run, so operationally yes — but the gate is the control that separates preparing payroll from committing it, and payroll is exactly where a second pair of eyes pays for itself. If the seeded single step does not fit, reshape the process rather than abandoning it.
Who should the approver be?
Someone who is not the person preparing the run — the platform's maker-checker option can enforce that the submitter cannot approve their own request. Typically the finance controller or HR head approves what the payroll operator prepares.
The run was approved — why is it not posted?
Posting on approval can fail for configuration reasons (an unmapped component, a missing control account) without failing the approval. Check the run: approved but with posting status NotPosted means exactly this. Fix the named gap and post the run directly — see Troubleshooting payroll.
Can we approve on mobile?
Yes — payroll runs surface in the same approvals inbox as every other entity, on web and on mobile, with the same decisions available.