A two-step guided wizard for importing mid-year workforce data into Finity Pay — eliminating the manual spreadsheet transformation that caused data errors in over half of all client migrations.
.timeline
3 months
.year
2025
.tools
Jira, Figma, Miro, Confluence, Claude Code
.role
Product Lead
Every payroll system stores data differently — column names, field formats, value conventions all vary by vendor. Before this existed, clients switching to Finity mid-year had to manually clean, remap, and transform their workforce data before it could be imported. Some exports contained over 120 columns per employee. Research shows more than 80% of large spreadsheets contain critical errors, and in payroll the consequences are severe: workers paid incorrectly, or wrong employment records filed with HMRC. In the 12 months before this tool launched, 30% of onboarded clients required a data fix after submission to HMRC, and a further 25% had errors caught by our support team before they reached HMRC. More than half of all migrations had a data problem. For a client switching payroll provider, this was their very first experience of the product.
I identified that every UK payroll product — regardless of vendor — submits workforce data to HMRC in a standardised file format called an FPS. That meant every client already had their data in a clean, structured format we could accept directly. I designed a two-step migration wizard: step one imports the FPS file and handles all field mapping automatically; step two captures supplementary data outside the FPS — contact details, pension status — via a guided column-matching interface or a downloadable template. Since launching, we've had zero data fixes required post-migration. One client migrated seven employers' worth of workforce data in a single day — a process that previously took one to two weeks per employer.
When a business switches payroll provider mid-year, they're moving live employees — people with active tax records, ongoing pension contributions, and upcoming pay dates. Getting it wrong doesn't just cause admin headaches; it creates incorrect RTI submissions to HMRC and risks workers being paid wrongly. For Finity, this was also the first experience new clients had of the product. Before I addressed it, it was by far the highest-risk moment in our customer relationship.
I identified the problem through a pattern in our support data. In a 12-month retrospective, I found that 30% of onboarded clients needed a data fix after incorrect records had already been submitted to HMRC — and a further 25% had errors caught proactively by the support team before submission. That's 55% of all migrations with a data quality issue. The root cause was always the same: clients were being asked to manually clean and reformat their data to match our import schema, under time pressure, in large unwieldy spreadsheets.
The insight that unlocked the solution came from my payroll domain background. Every UK payroll system — regardless of vendor — submits workforce data to HMRC in a standardised file format: the Full Payment Submission (FPS). I realised we weren't using this. Instead of asking clients to transform their data into our format, we could accept the FPS file they already had and do the mapping ourselves. I used Claude Code to reverse-engineer the FPS field mappings from our existing employee controller and importer — extracting exactly how our system interpreted and translated FPS data — and used that to define the complete mapping schema for the new import tool.
The harder problem was scope. I identified early that the FPS alone isn't a complete employee record — as a payment submission file, it carries tax and period data but not contact details, pension status, or other supplementary fields. A naive implementation would have solved half the problem. I made the call to design a two-step wizard: FPS import first, then a supplementary import step where clients could either download a pre-populated template or upload their own file and map columns through a guided interface. This was a more complex build, but it meant the tool handled the full migration — not just part of it.
The results were immediate. One client migrated seven employers' worth of workforce data in a single day. Previously the same process took one to two weeks per employer. Since launch we've had zero data fix incidents — the entire category of post-migration HMRC corrections has been eliminated. A client called it "bloody brilliant," which remains the best product feedback I've received.
If I were doing this again, I'd have pushed to instrument the supplementary import step earlier — we didn't capture drop-off data at launch, which would have helped us iterate on the column-mapping UX faster.
Every problem worth solving has a human at the centre of it.