Payroll consolidation as four controlled steps, demonstrated end to end
A listed payments company consolidated payroll from many entities and providers by hand. We built a four-step system inside its own office suite, demonstrated it end to end and handed it over for user-acceptance testing.
Context
The People function of a listed global payments company pays its staff through many legal entities and several payroll providers. Every month those providers return files with different layouts, currencies, concept names and number conventions, and someone has to turn them into one consolidated view.
That work lived in spreadsheets. Reports were gathered into separate sheets, copied into a consolidated workbook and checked by hand against People data. The process owner estimated that preparing and validating the file took about 20 hours a month: a practitioner's estimate, not an audited baseline.
The project began as one practitioner's use case in a wider AI enablement programme we ran for the function, then became a named People Operations project.
The challenge
A manual consolidation hides its own risks: an amount typed as text, a decimal comma read as a thousands separator, one concept labelled differently by each provider, a leaver still on a provider's file. Each can pass unnoticed when the control is a person scanning thousands of rows against a deadline.
Two constraints shaped the design. The solution had to live in the office suite the team already used: no new platform to procure, secure and learn. And the team's review had to stay inside the process: the system could prepare, validate and flag, but approving payroll remained a human decision.
Our approach
We treated the work as a small piece of financial-operations software, not a clever spreadsheet: the control boundary and design decisions were written down before the rebuild, and real historical cycles replaced invented samples.
- 1Requirements with the process ownersWorking sessions with People Operations on provider files, calculations, exchange rates, entity handling and the controls the team already ran by hand.
- 2A first version, reviewed on historyShown about three months after requirements and reviewed against historical examples to check the calculations.
- 3Read-only audit of the legacy filesEarlier test workbooks diverged too far to reconcile line by line. We kept them as a library of parser failure modes.
- 4Reference cycles as the targetTwo recent monthly cycles, prepared with more care by the client, became the reference cases for the parser and the controls.
- 5Rebuild, demonstration and handoverRebuilt around a deterministic orchestrator, all four steps were demonstrated in the client's environment and handed over, with a user manual, for practitioner testing.
The schedule was not a straight line. The work slipped after the requirements sessions, and the client asked us to resume and move to concrete results.
What was built
The system is a set of Google Sheets workbooks driven by Apps Script and operated from a private sidebar in an orchestrating spreadsheet. It was built and demonstrated inside the client's own Google Workspace, not on a platform of ours.
- Prepare. Generates the month's input workbook from a template under a fixed naming and versioning convention.
- Validate. Checks incoming provider data and surfaces exceptions before consolidation: ambiguous or unparseable amounts, unmapped concepts, unrecognised entities or currencies.
- Consolidate. Standardises payment concepts, applies exchange rates, enriches records with HRIS data and writes a new versioned payroll file.
- Review. Generates the controls inside that file: period-on-period comparisons, an exceptions view and the checks the team used to run by hand.
The control set was designed to make the process owner's manual checks repeatable. It compares payroll with HRIS headcount to find people paid but not on record, or active but unpaid, and it covers leavers, salary drift and movement in entity totals. Each consolidated row is designed to keep a pointer back to its source file, tab and row, with the raw amount beside the parsed one.
Three decisions matter more than the code. Source files are read-only evidence: the system is designed never to edit what a provider sent. Normalisation must not silently rewrite an amount; formats are parsed by explicit rules and ambiguity is surfaced, not guessed. And every output is a new version, with runs logged.
Results
The honest summary: the system was built, demonstrated end to end in the client's environment and handed to the process owner for user-acceptance testing. That is where our evidence stops.
A characteristic of one run, not a productivity measure.
Each held roughly 9,000 rows.
We publish no time saving for this case. We have an estimate of the manual baseline but no measurement of a live cycle, so any percentage or hours-saved figure would be invented. Nor does a demonstration establish an error rate.
Several items were open at handover: the exchange-rate source for one market, prior-period baselines, the classification of leave and holiday concepts, some HRIS report inputs, and business testing by the team. We hold no record of formal acceptance, of a completed reconciliation against the reference cycles, or of a live payroll cycle on the system, so we claim none of them.
Governance and risk
Controls were designed with the automation, not added after it. The review step reports risk and leaves the decision with the team; it does not approve payroll. Period-on-period checks need a prior period; the design reports a missing baseline instead of fabricating a comparison.
Access relies on the client's own Workspace permissions. The tool is a private, spreadsheet-bound sidebar, not a public web application, shared only with approved People Operations users. The design adds a server-side allowlist check before any payroll action.
Two limits remain. The control thresholds are technical defaults, not accounting policy, until the client's People and finance owners approve them. And at handover the code repository had a single author, with no independent review trail or automated test pipeline; nor do we hold a record of a client security approval. Those three gaps should be closed before a live cycle relies on the system.
What we learned
- Agree the control boundary first: what the system may prepare, validate and flag, and what remains a human approval. Every later design choice follows from it.
- Treat provider files as read-only evidence and version every output. A reviewer values a trail back to the source row more than speed.
- Keep language models out of calculation paths. A reviewer can check deterministic code against reference cycles; a probabilistic answer cannot be checked that way.
Client identity, locations and identifying details are withheld under confidentiality. Figures are rounded. Measured figures come from engagement records; client-reported figures are attributed, not audited; modelled figures are projections from the engagement's business case and are labelled as such.