Launch HN: Onfolk (YC S21) – Modern HR and Payroll in One Place (For the UK)

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

Hello from a fellow UK HR (ish) company. This looks like a strong start - payroll is hard!

Good luck, we all need to band together to get rid of these insane portals of horrible UX

There's quite a few modern HR platforms floating around, like CharlieHR, and it seems (as an outsider) that these platforms have explicitly decided not to enter payroll because it's such a nightmare. From my own experience, payroll is very hands-on because of edge-cases: make one mistake with one employee and you're sixty emails deep with a payroll administrator trying to clear things up (I've been on the receiving end of payroll hell quite a few times in my career!).

I think applying best engineering practices to business problems (i.e: unit testing your payroll logic) is a vastly undervalued opportunity and I think offering a payroll API is a fantastic opportunity for companies like CharlieHR to gain this functionality.

1. If we use CharlieHR as an example, how do you tackle building a relationship with them as a service provider (Payroll API) while competing with them on the product side? CharlieHR would need to disclose the relationship to their customers (since the data would be shared) -- do you plan to spin out a separate "brand" for the API?

2. How do you accommodate the inevitable Payroll hell: do you have (or plan to have) a staff of payroll administrators (and accountants?) to handle the edge-cases? Are you insured against any mistakes? Have you encountered any challenges so far / identified any big wins?

Thanks and good-luck, I'll pass this on to our HR team!

I wish that list existed! You're right, there's tons. HMRC have a few test cases you have to pass in order to get recognition, but it's the tip of the iceberg. Getting recognition does not mean you're done.

What we've strived for is to make our software super defensive to input it hasn't seen before. So if you enter a tax code or national insurance category that isn't strongly defined, we error, get alerted, then jump on it (instead of falling through to some default behaviour).

One nice thing is that a few of our customers give access to their accountants, who are very on it with challenging us if anything doesn't look perfect. When we get a report, usually it's an accountant telling us ahead of time vs. a customer finding out on payday, which is a sanity check we're grateful for.

1. We're still figuring that one out. From an HR software's point of view, we think they ideally want the payroll API to be white-labelled, so that their customers don't have to think about another product. We're not yet experts on the legal relationship here, but I imagine disclosure can be covered in a privacy policy and we're the "data processor" for them under GDPR. As far as a separate brand for the API, it's a little early to say. We're talking to lots of people at the moment about their use cases. I think we'll figure out how to market it later on.

2. We do indeed have liability insurance! We usually have the accountants of our customers raise any weirdness to us before payruns / run things in parallel for a month or two before going live. That's thankfully become much less common as we've done more reps.

In our second month of payruns we made an error where we didn't factor in the 4k employer allowance in the UK for one of our customers, which resulted in their PAYE bill being off.

The only way to react to those moments in my experience is to admit it and own it. Doing everything in your power to communicate exactly what went wrong, rectify the issue (usually via a correction to HMRC made over their API), and put tests in place to ensure it can't happen again. Integration tests can really help here, defining the exact scenario that led to the weirdness and asserting that the correct response comes out from now onwards.

Thankfully it's been a while since something like that's happened. We've had offers from a few payroll pro's to stress test the product which we'll definitely be taking them up on.

The trickiest scenarios that often catch people out are when employees move from part-time to full-time or paid weekly to paid monthly. So far we only support monthly payroll, but we'll definitely move into weekly at some point. Time is hard!

I dearly wish that every month was 28 days long.

Another tricky thing is communicating to customers things like how income tax is calculated. It's not done per month, but based on the amount you've paid so far this year. The method is different for directors, for whom you get to choose between two methods of calculation: https://www.gov.uk/employee-directors