Payroll Software UX: Show the Variance Before You Ask for the Approval

Every payroll product has a moment where it asks a tired admin to press one button and move real money into dozens or hundreds of bank accounts. We think that moment deserves more design attention than any other screen in the product.

Spend an afternoon reading what payroll admins say about their tools in r/Payroll or in the threads that follow any big redesign, and one sentence keeps coming back in different words: I don't trust the preview screen. People export the register to a spreadsheet, print PDFs, and screenshot pay stubs before they submit, because the software never gave them a way to be sure. When your users build a parallel audit system outside your product, your review screen has failed, however clean it looks.

This is how we think about payroll software UX at UX Signal Studio, and what we reject when we review or rebuild a payroll flow.

The real job is confident approval

A payroll run has a lot of inputs: hours, overtime, PTO, bonuses, reimbursements, garnishments, benefit deductions, new hires, terminations, and tax changes. The admin's job is rarely data entry. By the time they reach the run, most of that data arrived from time tracking, HR records, and benefits systems.

So the admin is an approver. Their real question is short: is anything in this run different from what I expect, and do I understand why? Every screen in the run should help answer that question faster. A screen that only displays numbers, without telling the approver which numbers changed and why, pushes the real work into a spreadsheet.

We design payroll around three questions, in this order:

1. What is still blocking this run?
2. What changed since last time, and is each change expected?
3. What exactly happens when I press approve, and when?

Blockers belong at the front door

The most common structural mistake we see is a "Start payroll" button that sits in front of the information admins need to decide whether to start. Pending timecard approvals, missing bank details for a new hire, an unresolved tax setup, a direct deposit change waiting for review: all of these get discovered three screens into the run, after the admin has already committed mentally.

Put blockers on the landing view of the pay period, before any start action. Each blocker should name the person, the problem, and the fix, with a direct link to resolve it. When a blocker is resolved, the item should visibly change state so the admin knows the fix took. Admins in usability studies regularly fix something and then cannot tell whether the fix worked. That uncertainty is exactly what drives them back to exports.

Also watch the verb. "Start payroll" reads to many admins like "send payroll." If the action only opens a draft, call it what it is, for example "Open draft run," and keep the money-moving verb for the final step.

Variance is the product

Payroll is repetitive by design. Most employees should be paid roughly the same amount as last period. That makes the difference between this run and the last one the most valuable signal on the screen, and most products bury it.

Here is what good variance design does:

• Shows gross and net totals on the approval screen itself. Approvers should never have to visit a separate debit summary to see the total they are approving.
• Ranks employees by size of change, with the biggest swings at the top, and lets the admin sort alphabetically when they need to find someone.
• Explains every change in plain language next to the number. "Overtime 12 hrs" or "Bonus added by J. Rivera on Oct 28" tells the approver what happened. A bare code like OT2 or ADJ forces a lookup.
• Makes large variances loud. A 50 percent swing in someone's pay deserves color, weight, and position. Small grey comparison text next to a chart is easy to miss, and in testing it gets missed.
• Lets the admin mark each flagged change as reviewed, with that state saved and visible to a second reviewer.

One nuance matters a lot. In healthcare, manufacturing, and hospitality, pay swings every period because of overtime, shift differentials, and PTO. A simple period over period comparison turns every row red and becomes noise. For those customers, compare against a better baseline: the employee's rolling average, their scheduled hours, or their approved timecards. Variance logic should match how the business actually pays people, so the baseline itself is a product decision.

Name the consequence of every action

Payroll interfaces are full of small buttons with large consequences. "Dismiss" on a pending bank account change can read as reject to one admin and acknowledge to another. "Unsubmit" can quietly reset calculations. "Skip" on a deduction can mean this period only or forever.

Our rule is simple: every action in a payroll run states its consequence in the label or directly beneath it. "Mark as reviewed." "Remove from this run only." "Reopen run, totals will recalculate." If an action reverses or reopens something already approved, the product should show what will be recalculated and what will stay the same before the admin confirms. Admins have described reopening a run and having leave pay and salary both paid out. Whatever the cause, the interface gave them no warning, and that is a design failure as much as an engineering one.

The final review is a receipt, written before the money moves

The last screen before approval should read like a receipt the admin could hand to their CFO. It should include:

• Total gross pay, total net pay, employer taxes, and total debit amount
• The bank account being debited and the exact debit date
• The employee pay date, plus any employees paid by check or on a different schedule
• Count of employees in the run, with new hires and terminations called out
• Every flagged variance and whether it was reviewed, and by whom
• The cutoff time after which the run can no longer be changed

Then give them a one click export of exactly that summary. Admins will keep their own records anyway. Let your product be the source of the record so they stop rebuilding it by hand.

Two people, one run

Many small teams run payroll with one preparer and one approver, often a founder or an outside accountant. Most payroll products bolt approval on as an email with a link. The approver lands on a screen with no context and approves because the email told them to.

Design the approver view as its own surface. It should open on the receipt, show the variances the preparer already reviewed, highlight anything the preparer left unreviewed, and let the approver leave a comment on a specific employee line instead of sending a Slack message. When approval is a real step with its own screen, the second set of eyes actually looks.

After payday, design the correction

Payroll mistakes will happen. What separates good products is how quickly a correction can be made and explained. Off cycle runs, reversals, and retro pay adjustments should start from the original run with the context attached, and the employee facing pay stub should explain the adjustment in a sentence. A pay stub that shows a mystery deduction creates an HR ticket. A pay stub that says "Correction for overtime missed on Oct 15 run" closes one.

What we reject

When we audit or rebuild payroll software UX, these patterns go on the reject list immediately:

• A start action that appears before blockers are visible
• Approval screens without gross and net totals
• Earnings and deduction lists ordered by internal code instead of plain names
• Variance shown only in small text, or only on a separate report
• Buttons like Dismiss, Skip, or Unsubmit with no stated consequence
• Approver flows that begin from an email link with no summary
• Redesigns that move familiar controls without a migration path for daily users
• Reopen or unsubmit actions that recalculate without showing what will change
• Pay stubs that list adjustments with no explanation

Why we prototype payroll in working software

Static mockups make payroll look solved. A Figma frame with twelve tidy employees and round numbers hides everything that makes payroll hard: three hundred rows, mixed pay schedules, a retro adjustment, a terminated employee with final pay, and a variance threshold that fires on half the team.

We build payroll flows as working prototypes with realistic data, so real admins can run a messy pay period and tell us where their trust breaks. Our senior designers use AI to generate edge case data sets and stand up working screens quickly, and they keep the judgment calls: what counts as a meaningful variance, which actions need confirmation, and what the approver must see. That combination gets a payroll team to a flow they can test in days.

Want a second set of eyes on your payroll flow?

If your customers export to spreadsheets before every run, or your support queue fills up after each payroll update, we can help. We review payroll and other money movement flows for fintech and B2B SaaS teams and rebuild them as working software.

Book a discovery call or email ash@uxsignalstudio.com.