Payroll Reconciliation & Variance Analysis

The control flow a finance team actually needs.

The ERP surface involved.

Variance report must flag individual and aggregate changes exceeding configurable dollar and percentage thresholds; drill-down from variance row must open the underlying employee payroll detail without additional navigation steps; annotations must be retained and exportable for audit purposes; reconciliation must compare current-period actuals against prior period and approved budget; report must run within 2 minutes for a 10,000-employee company; all reconciliation sign-offs must be captured with user ID and timestamp.

US and UK teams have different compliance hooks, but the same control problem.

US teams usually care about clean evidence for audit support, vendor records, payment controls, tax reporting, and management review. UK teams usually care about VAT-ready records, approval evidence, digital-record discipline, and traceable postings. The country-specific details differ, but the operating pattern is the same: the ERP needs controlled records, explicit ownership, defensible state changes, and evidence that survives beyond the person who completed the task.

The control matrix.

Audit evidence is a chain, not a folder.

After each pay run, the system generates a period-over-period variance report comparing gross wages, deductions, employer taxes, and headcount by department;
the Payroll Administrator investigates variances exceeding configurable thresholds (e.g., >5% change in any cost component);
root-cause drill-down links variance rows to specific employee records and pay events;
Administrator annotates each variance with an explanation;
Controller reviews the annotated report before approving the payroll journal for GL posting.

payroll_variance_report { id: string, current_run_id: string, prior_run_id: string, external_id: string, generated_at: timestamp, status: enum(PENDING,REVIEWED,SIGNED_OFF) };
variance_line { id: string, report_id: string, category: string, current_minor: int64, prior_minor: int64, variance_minor: int64, variance_pct: decimal, currency_code: char(3), annotation: string, annotated_by: string };
(reference, product may differ).

POST /v1/payroll-variance-reports { current_run_id, prior_run_id, external_id } -> 202 async -> 201 { id };
GET /v1/payroll-variance-reports/{id} -> 200 { lines[], status };
POST /v1/payroll-variance-reports/{id}/sign-off { annotations[] } -> 200 { status: "SIGNED_OFF" };
emits payroll.variance_report_signed_off;
idempotent via external_id.

PENDING -> REVIEWED -> SIGNED_OFF;
guard: payroll journal POSTED blocked until report SIGNED_OFF;
variance lines exceeding threshold require annotation before SIGNED_OFF.

The useful version of this workflow is not only fast. It is inspectable. A controller, auditor, or operator should be able to move from source event to system record to state transition to final business outcome without guessing.

Implementation contracts.

`payroll_variance_report` { id: string, current_run_id: string, prior_run_id: string, external_id: string, generated_at: timestamp, status: enum(PENDING,REVIEWED,SIGNED_OFF) }; `variance_line` { id: string, report_id: string, category: string, current_minor: int64, prior_minor: int64, variance_minor: int64, variance_pct: decimal, currency_code: char(3), annotation: string, annotated_by: string }; (reference, product may differ).

`POST /v1/payroll-variance-reports` { current_run_id, prior_run_id, external_id } -> 202 async -> 201 { id }; `GET /v1/payroll-variance-reports/{id}` -> 200 { lines[], status }; `POST /v1/payroll-variance-reports/{id}/sign-off` { annotations[] } -> 200 { status: "SIGNED_OFF" }; emits `payroll.variance_report_signed_off`; idempotent via `external_id`.

`PENDING -> REVIEWED -> SIGNED_OFF`; guard: payroll journal POSTED blocked until report SIGNED_OFF; variance lines exceeding threshold require annotation before SIGNED_OFF.