Payroll run approval

Payroll run approval is an optional sign-off between calculating a payroll run and posting it: an approver reviews the calculated run, and their final approval posts the run's accrual to the ledger automatically. It sits between Step 4 (review the figures) and Step 7 (generate the payment) of running payroll. Without it, the payroll operator posts the run by clicking Post.

Overview

Payroll runs use the platform's general approval processes. What is special about payroll is what happens after each decision: xMatix copies the outcome onto the run and, on final approval, posts the run in the same way Post does. Approving a payroll run therefore commits it to the books. Approval is not only a status stamp.

xMatix does not ship a payroll approval process. A new organization has none, and payroll runs are posted directly with Post until an administrator creates one. Your organization may already have a process on Payroll Run from an earlier setup. Check Setup → Process Studio → Approvals before you create one.

When to use it

Add the approval gate when the person who prepares payroll should not be the person who commits it, for example when a payroll operator calculates the run and a finance controller or HR head signs it off. If one person runs and posts payroll, you don't need it.

How xMatix handles it

When a payroll run reaches a final decision, xMatix updates the run as follows. It never changes a run that is already posted.

Three things follow from this:

• A decision never un-posts a run. Rejecting, recalling or reverting after the run has posted leaves the journal and open items in place. A reverted request on a posted run leaves Approval Status at Pending, but no request is waiting for anyone.
• Approval does not freeze the figures. Calculate and Post still work while a request is pending, even when the process locks the record. A run recalculated while pending is approved with its new figures.
• Post does not check approval. Anyone allowed to click Post can post a run without approval. To make approval the only way to post, take the Post action away from everyone except the approval path (see Permissions).

Prerequisites

• To create or change the process: the approval administration capability on your security profile (see Approval processes).
• Payroll set up so that posting succeeds: GL accounts on every component line and a Payroll Payable control account (see Payroll configuration). If posting fails, the run is approved but not posted.
• A named approver, team or security role for each step.

Procedure

Step 1 — Create the approval process

1. Go to Setup → Process Studio → Approvals and click New.
2. Enter a Label (for example "Payroll run approval") and a Name, and choose the Entity Payroll Run.
3. Leave Active off for now. Set Allowed submitters to Anyone with access, unless only a role or team should submit.
4. Save. The process opens on its own page.

Step 2 — Decide when a run is submitted

On the process page, open Behaviour:

1. Set Entry Condition to Status == "Calculated". A run then qualifies only after Calculate has run, so the approver always sees real figures.
2. Turn on Enable Auto-Submit and set Event Type to On Update. Each time a calculated run is saved, including the save that Calculate makes, xMatix submits it if it has no pending request.
3. Leave Auto-Submit Condition empty. It has no effect; the Entry Condition decides.
4. Turn on Allow Submitter Recall if the operator should be able to withdraw a submitted run.
5. Turn on Lock Record on Submission if nobody should edit the run's fields while it waits.

Don't use On Create with an entry condition of Status == "Draft". The run would be submitted before it has any figures, and approving it then posts nothing (see Common problems).

Step 3 — Add the approval steps

On the Approval Steps tab, add one step for each person or group that signs off. For each step, set the Order, a Label and the Approver Type: Specific User, Security Role, Team or Submitter Chooses. Then choose the approver.

• On rejection: Reject the whole request sends the run back to Review. Send back to previous step returns the request to the earlier step and leaves the run unchanged. On the first step it always rejects.
• Require Unanimous: when the step resolves to several people, every one of them must approve.
• Timeout Action: leave it at None for payroll, so a run is never approved without a person deciding.

Step 4 — Leave the run's status to xMatix

Don't add field updates for Status in a step's On Step Approval — Field Updates or On Step Rejection — Field Updates. xMatix sets the run's Status and Approval Status itself (see How xMatix handles it). If you want the run to show that it is waiting, open Lifecycle Actions and add a Field Update On Initial Submission that sets Status to the stored value PendingApproval.

Set the notifications you want under Notifications: On Submit, On Approve, On Reject, On Recall and On Revert.

Step 5 — Give users the approval controls

The standard payroll run page has no Submit for Approval button and no Approval Panel. Approvers can still act from the Pending Approvals page (Step 6). To let people submit, recall or revert from the run itself, edit the payroll run's record layout in the layout designer:

• add Submit for Approval to the page header's actions. It is offered once an active process exists for Payroll Run;
• add the Approval Panel widget to show the request's status, its history and the recall and revert controls.

Do the same on the mobile layout if approvers work on mobile. The standard mobile payroll run page has no approval panel either.

Step 6 — Activate and test

1. Turn on Active and save.
2. Create a test run, click Calculate and confirm that a request appears on the approver's Pending Approvals page.
3. Sign in as the approver and click Approve. The run's Status becomes Posted, and its Related tab shows the journal and the employees' open items.

Step 7 — Approve or reject a run (approver)

1. Open Pending Approvals (the Approvals inbox). The list shows the entity, record, status, step and submission time of each request waiting for you.
2. Open the payroll run and review it, following Step 4 of running payroll.
3. Click Approve or Reject on its row. To decide several at once, tick them and click Approve Selected or Reject Selected. Requests you are not allowed to act on are skipped.

After the final approval, the run is posted. After a rejection, the run is back in Review. The operator corrects the inputs and clicks Calculate again, which sets the status back to Calculated and, with the Step 2 setup, submits it again.

Business rules

• One open request per run. A run can have only one pending request. Saving it again while a request is pending doesn't submit a second one.
• Final approval posts once. A run that is already posted is never posted again. Posting needs calculated component lines, a GL account on every line and a Payroll Payable control account.
• A posting failure does not undo the approval. If posting fails on final approval, the request stays Approved, the run's Status and Approval Status don't change, and nothing is posted. The error is logged, not shown to the approver.
• Recall is for the original submitter only, while the request is pending, and only when Allow Submitter Recall is on. With auto-submit, the submitter is the person whose save submitted the run.
• Revert applies only to an approved request.
• Lock Record on Submission stops users editing or deleting the run through its forms while it is pending. It does not stop Calculate, Post or the other run buttons.
• The approval does not cover the employee rows. The rows and component lines of a pending or approved run can still be edited by hand. See running payroll for why you should recalculate instead.

Example

A company pays 40 employees. Its payroll operator prepares the run and its finance controller signs it off.

1. The administrator creates "Payroll run approval" on Payroll Run, with the entry condition Status == "Calculated", auto-submit On Update and one step whose approver is the finance controller. They add Submit for Approval and the Approval Panel to the run's page and activate the process.
2. On 28 October the operator creates the October run and clicks Calculate. The run becomes Calculated and is submitted at once.
3. The controller opens Pending Approvals, reviews the run and notices a missing festival bonus. They click Reject. The run's Status becomes Review.
4. The operator enters the bonus as a payroll adjustment and clicks Calculate again. The run is Calculated again and a new request reaches the controller.
5. The controller approves. The run's journal is dated on the period's pay date (or its end date when no pay date is set), and 40 net-pay open items are ready for the salary payment batch.

Training

Practice exercise

In a sandbox with payroll set up, create an approval process on Payroll Run as in Steps 1–6, with yourself as a Specific User approver. Create a run for a past month and click Calculate. Reject the request from Pending Approvals, click Calculate again, then approve the new request.

Expected result: after the rejection, the run's Status is Review and nothing is posted. After the second Calculate, a new request is waiting. After approval, the Status is Posted and the Related tab lists one journal.

Quick reference

• xMatix ships no payroll approval process. Create it at Setup → Process Studio → Approvals.
• Use the entry condition Status == "Calculated" with auto-submit On Update.
• Final approval posts the run. Approve only figures you have reviewed.
• Rejection sets Review, recall sets Draft, and nothing ever un-posts a run.
• Post bypasses approval. Restrict who has it.
• Add Submit for Approval and the Approval Panel to the run's page yourself.
• An approved run that didn't post is a posting setup problem. Fix it, then click Post.

Permissions

The approval decision is not controlled by the payroll grants on security profiles. To make approval the only route to posting, remove the Post action from the payroll users' profiles in security profiles. Final approval still posts, because it is the approval path and not the Post button that posts the run.

Configuration

Common problems

The run was approved but it isn't posted

Cause: posting failed on final approval, most often because the run was approved before it was calculated, a component line has no GL account, or no Payroll Payable control account exists. The approval stays Approved, but the run's Status doesn't change. Fix: click Calculate if the run has no lines, fix any GL mapping, then click Post. Post shows the reason if it still fails, for example "Payroll run has no calculated component lines to post (calculate first)." To stop runs being submitted before calculation, use the entry condition in Step 2.

Nothing reaches the approver after I click Calculate

Cause: the process is not active, Enable Auto-Submit is off or set to On Create, the entry condition doesn't match the run, or the run already has a pending request. Fix: check the process's Behaviour settings against Step 2. An entry condition that can't be evaluated turns the gate off without telling you, so check its field name and quotes.

There is no Submit for Approval button on the run

Cause: the standard payroll run page doesn't list it. Fix: add Submit for Approval to the run's page header in the layout designer (Step 5). It can be added only while an active process exists.

"Maker-checker: the submitter cannot approve their own request; a separate approver is required."

Cause: the process requires a separate approver, and you submitted the run, possibly by clicking Calculate with auto-submit on. Fix: let another approver decide, or reassign the step.

"Only the original submitter can recall an approval request."

Cause: someone other than the submitter tried to recall the request. Fix: ask the submitter to recall it, or ask the approver to reject it.

"You have already approved this step."

Cause: you approved this step of a unanimous request already, and the other approvers are still to act. Fix: nothing to do. The request moves on once the remaining approvers approve.

Common questions

Can we run payroll without approval?

Yes. A new organization has no payroll approval process, and the operator posts each run with Post. Approval is worth adding when preparing and committing payroll should be done by different people. A second reviewer catches a missed adjustment or a wrong period before it reaches the ledger, and an approval history records who signed off. If you add it, also restrict the Post action, because Post works whether or not a run is approved.

Does rejecting a posted run reverse it?

No. A rejection, recall or revert never changes a run that is already posted. The journal and the employees' open items stay, and the run's status stays Posted. Payroll runs have no reversal action, so a posted run can't be undone through approval. That is why the approver should review the figures before approving, and why the entry condition should let only calculated runs in. If a posted run is wrong, correct the difference in the next month's run with a payroll adjustment.

Can we approve payroll runs on mobile?

Yes, once your administrator has set it up. The standard mobile payroll run page has no approval panel. An administrator either adds the Approval Panel to the payroll run's mobile layout, or places an Approvals inbox widget on a mobile page. Approvers can then approve or reject from the record or the list, with the same rules as on the web. Final approval on mobile posts the run, just as it does on the web. See Approvals on mobile.

Who should approve?

Someone who did not prepare the run, typically the finance controller or HR head. To enforce this, ask for maker-checker on the process, which stops the submitter approving their own request. With auto-submit, the submitter is whoever clicked Calculate, so the payroll operator can't approve their own run.

Related topics

• Running payroll
• Approval processes
• Approvals on mobile
• Payroll configuration
• Troubleshooting payroll
• Security profiles
• Payroll Run — entity reference