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. Start with decisions and users, then add only measures whose definitions and data lineage are understood. Do not expose employee-level information merely because the source system contains it.

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 a workflow-state panel

Show expected payrolls by employer and pay date, then separate not started, in progress, awaiting approval, transmitted, acknowledged, rejected, corrected and reconciled states. HMRC's running payroll guidance provides a process reference, while the product's supported workflow determines the exact end point.

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.

Add commercial context separately

Show active paying employers, completed payrolls, implementation work, support minutes, renewal and cohort margin. Do not mix marketing leads into operational completion or use 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.

Suppress duplicate noise without hiding distinct affected payrolls. Record when an alert opened, who accepted it, what evidence was checked and how it closed. During an incident, preserve the original readings so that later data repair does not erase the response timeline.

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.