Hey, we’re Naz and Charlie! We're building Onfolk (https://onfolk.com/). We’re a couple of engineers who discovered that payroll in the UK is pretty backward and that building good software can raise the bar. You can check out some pics on our Product Hunt post [1] or see a quick video [2].

To set the scene: we were software engineers at Monzo for 4 years. Joined at 400k customers, left at 5.5M. We took voluntary furlough in April 2020 ("furlough" is the UK government’s scheme for keeping workers paid for a bit so that companies don't have to lay them off). During that time, Monzo changed payroll provider. The old one sucked and had errors. The new one sucked and had errors. It took a consultant a year to implement the new one.

We wondered how on earth a company with our funding, whose main asset was its people, couldn't find a good way to pay them. We dug into what doing payroll actually means (shout out to payroll guru Duane Jackson [3] for the early pointers!). Turns out, payroll is: (1) gross-to-net calculations, (2) reporting that to the government, and (3) making payslips. It’s not conceptually hard but you have to be meticulous. Complicated, not complex.

Some of the payroll products in the UK have 0 automated tests in their software. A typical process is run on spreadsheets pulled out of HR softwares or emails to accountants. No validation, data keyed in on the other end. Payroll is unloved.

There are a huge amount of edge cases. Tax systems aren't put in place all at once – they evolve over time. So when you're programming payroll you run into things like: gender is a mandatory field to report to the government and a binary male/female. Until April 1977 married women could choose to pay a reduced rate of national insurance (our word for "social security" in the UK). Anyone who opted into that scheme before 1977 might still be on it.

Another one: Deep-sea fisherman have their own national insurance rates [4]. The government changes people's tax codes periodically, and sometimes the reasons can seem baffling. It's not a very transparent system

Turns out the competition is listed on the government's website [5]. There’s about 130 other payroll softwares. Desktop software still dominates the UK market ("butt" is a feature in payroll land).

We discovered the certification process to get on the list, found the right person in the government to email when we had questions, and kinda just started building. We trundled on over our weekends until we got on the list (might still be under our old name, “Hyko”, at the time of writing. Hyko is a dog [6]).

Then, a friend whose payroll provider had just got their numbers wrong gave us a shot. I phoned up Charlie, who said “I guess I’d better put the kettle on”. We had less than 2 weeks to get it done and worked like maniacs over Christmas to arrive at something that looked like a payrun.

The calculations were run from test files on our local machines, as was notifying the government via their XML API with it's random polling intervals. Payslips were cobbled together on Figma. It was artisanal.

Since then, here’s a few ways we’ve tried our best to raise the bar on the software side: Thorough automated unit tests on our calculation logic; integration tests for playing through multiple months of salaries (especially important as tax calculations in the UK care about the cumulative amount paid over a year vs. only concerning the current month); whenever anything changes, we recreate payments for the current month on the fly. So that the user always has a live view of what payroll will be (vs. finding out on the day); Reconciliation logic. So that if things that should add up don't add up, we error loudly way before payday. This reduces the chances that we'll ever run payroll with incorrect numbers (techniques learnt while interacting with banking ledgers); Wrote in a language with a strong compiler (Go); Generally validate the shit out of everything.

Since Christmas, the product has expanded from payroll into one tool for everything that touches employee data. We think that a ton of the manual admin work in UK companies results from no 'single source of truth' for employee data (often spread across Xero, accountants, spreadsheets, time-tracking software, Google Drive).

The same data is duplicated in multiple tools, which means it has to be synced, which means spreadsheet exports and manual process. e.g. when an employee leaves, you usually want their remaining time-off allowance to be automatically added to their final salary, reported to the government as such, and to have them removed from payroll, time-off rotas etc. Typically, that means a bunch of faffy jobs where people get paid wrong if you mess up.

We’ve tried to kick off everything that needs to be done from key actions (new joiner, leaver, salary update, payrun). When a payrun is started, from our backend: the UK government is notified, payslips are created, journals are posted to accounting software, pension contributions are posted, and payments are scheduled.

As an employee you don’t have to log in to “myEPayslipPortal” to get your payslip. It’s there alongside your time-off and personal info. Currently we charge £8 / employee / month and have a bunch of startups on board.

This autumn we’ll be working on exposing our backend as a UK payroll API, so anyone can have payroll in their product without having to care about unintuitive tax calculations and keeping up with changes in regulations.

I’d be interested if our findings ring true with anyone's payroll experiences. Any ideas for applications for a payroll API? Or interesting implications come to mind with having a source of truth for all your employee data?

Thanks all!!

[1] https://www.producthunt.com/posts/onfolk

[2] https://loom.com/share/3ac431db7c4e46e7a14921c5f98a3f68

[3] https://www.theguardian.com/society/2015/aug/16/i-got-caught...

[4] https://www.gov.uk/government/publications/ca42-foreign-goin...

[5] https://www.gov.uk/payroll-software/paid-for-software

[6] https://www.lukeleighfield.fyi/blog/hyko

user:	painroll
created:	July 14, 2021
karma:	6