A payroll dashboard that keeps workflow state, HMRC outcomes and corrections apart

A payroll dashboard should help someone act before a missed or incorrect outcome. Do not expose employee-level information merely because the source system contains it.

What to take away

Give each audience a view

An operator needs due runs, missing inputs, rejected reports and pension exceptions. A service owner needs completion, corrections, incidents and support demand. Finance needs cost and retained margin. Privacy and security owners need unusual access and incident information.

Avoid one crowded executive page that cannot support any of these decisions. Apply role-based access and aggregation.

Build these views in a dashboard tool such as Power BI, Tableau or Looker Studio, or use the reporting module in payroll software such as Xero Payroll, Sage 50 Payroll or BrightPay.

Build a workflow-state panel

Show expected payrolls by employer and pay date, then map each run to named HMRC RTI response statuses: successful, successful with errors, failed and pending.

Keep separate workflow states for not started, in progress, awaiting approval, transmitted, acknowledged, rejected, corrected and reconciled. HMRC's running payroll guidance provides the process reference, while the product's supported workflow determines the exact end point. For corrections, use HMRC categories such as an FPS correction or an EPS correction.

In England the tax year runs 6 April to 5 April. An FPS is due on or before payday, and the final FPS for the tax year is due by 19 April.

Highlight overdue transitions and name the current owner. A green "submitted" status is misleading when the receiving response is pending.

Add quality and correction

Display calculation exceptions, unresolved differences, report rejections, corrections and time to customer-outcome repair. Classify causes consistently. Link aggregated figures to restricted case records for authorised investigation.

Use the current HMRC correction guide to maintain operational categories, but do not put personal details or tax advice into a general dashboard.

Include pensions and dependencies

Show provider exchange state, rejected files, contribution differences and age of unreconciled items. Add integration and service dependencies affecting active payrolls, such as identity, time or payment systems.

Measure service and recovery

Report availability by critical journey, payroll-blocking incidents, support response, restoration and final resolution. Keep technical recovery separate from corrected payroll outcome. Include restoration-test age and unresolved incident actions. Preserve original readings during an incident so later data repair does not erase the response timeline.

Add commercial context separately

Show active paying employers, completed payrolls, implementation work, support minutes, renewal and cohort margin. Keep marketing leads out of operational completion and do not count imported employee records as active usage.

Publish definitions and protect data

For every tile, provide formula, numerator, denominator, time zone, refresh, source, exclusions and owner. Mark provisional data and preserve definition changes.

Design alerts around action

An alert needs a recipient, response window and documented next step. Useful examples include an acknowledgement still absent after its expected processing interval, several employers encountering the same calculation exception, or a pension difference remaining open past the team's control point. Treat thresholds as operational settings that require testing, not universal evidence of poor performance.

For an illustrative threshold, alert if an FPS still shows pending or failed two hours after the scheduled payday submission. The payroll operations lead owns it, the window is 30 minutes, and the next step is to check the HMRC response and resend before 17:00.

Suppress duplicate noise without hiding distinct affected payrolls. Record when an alert opened, who accepted it, what evidence was checked and how it closed.

Review the display before relying on it

Reconcile headline totals to source systems and trace a small sample from tile to case. Test empty, delayed and contradictory states. Confirm that dates use an agreed time zone and that pay-period comparisons contain equivalent cut-off points.

Run a tabletop exercise with an operator, service owner and senior decision-maker. Give them a rejected report, a pending pension response and a misleading spike caused by late data. Note whether each person finds the evidence and chooses the correct owner. Repair ambiguous labels before the dashboard is used for performance management.

Archive monthly definitions and access decisions. A later reviewer should be able to explain why an old chart differs from the present calculation without reconstructing undocumented queries.

The GOV.UK Service Manual's performance guidance recommends using performance data with user research and collecting from all channels. Apply the principle to product decisions without claiming a government reporting requirement for a commercial service.

Test the dashboard with the people expected to act. Record whether they identify the correct priority and understand uncertainty. A useful dashboard shortens detection and accountable response; it does not merely display more numbers.

Before you act

Common questions

What should a payroll dashboard show for an operator?

Due runs, missing inputs, rejected reports and pension exceptions. Use the workflow panel to show the HMRC RTI response beside each expected pay run.

How should alerts be designed on a payroll dashboard?

Set tested thresholds and suppress duplicate noise without hiding distinct affected payrolls. Record when each alert opened, who accepted it, what evidence was checked and how it closed.

What should be checked before relying on the dashboard display?

Reconcile headline totals to source systems and trace a small sample from tile to case. Test empty, delayed and contradictory states. Confirm dates use an agreed time zone and pay-period comparisons use equivalent cut-off points.