[HN Gopher] Launch HN: Onfolk (YC S21) - Modern HR and Payroll i...
___________________________________________________________________
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 PS8 / 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
Author : 4thstreet
Score : 91 points
Date : 2021-07-14 08:47 UTC (14 hours ago)
| gregorycarter wrote:
| Looks really cool. I am the CFO for a post series A company with
| 25 employees in the UK and last month migrated to Pento, who I
| guess you would consider a competitor?
|
| I love the new employee experience. Now payslips get synced
| straight into our HR system (HiBob) and everyone can delete the
| horrible MyEPayWindow website from their bookmarks.
|
| More importantly for me, the payroll administration side is
| significantly slicker. We used to spend significant time back and
| forth in emails with our payroll administrator providing manual
| updates of new starters and payroll changes. This was not
| scalable as our headcount grew. Now changes get synced
| automatically from HiBob. We actually pay slightly more to Pento
| than we paid the administration firm, but our calculation was
| that the time we saved was a bigger saving overall.
|
| Anyway I think you are playing in a great space and there is a
| huge market. I look forward to following your progress.
| miqkt wrote:
| One of my previous stints was with a small team that was building
| a cloud-based payroll and HR platform for the Australian market
| (potentially going abroad as well). It definitely opened my eyes
| to how complicated award rules can be.
|
| I also remember testing being a challenge, particularly when
| things like multiple backpays, accruals, or one off adjustments
| were involved.
|
| There was also an integration API, but I didn't stick around long
| enough to see it evolve enough for widespread third-party
| adoption.
|
| Anyway, congratulations on the launch!
| ir123 wrote:
| Congrats on the launch! Must take lots of guts to compete in a
| market with these many competitors. Hope this works out for you
| guys.
|
| One thing that caught my eye was that the other softwares do not
| have automated tests. How do you know this?
|
| Do you consider this to be a USP of your software? I do not think
| end users will care about whether tests exist or not.
| 4thstreet wrote:
| > One thing that caught my eye was that the other softwares do
| not have automated tests. How do you know this?
|
| Talking to ex-employees
|
| > Do you consider this to be a USP of your software? I do not
| think end users will care about whether tests exist or not.
|
| I wouldn't go so far to call it a USP (many payroll softwares
| will test decently), more a baseline for quality. It's not
| uncommon to hear of payroll errors when talking to people who
| run payroll. While end users don't care about tests, they very
| much care about being paid the correct amount.
|
| These errors seem to fall into two categories: manual entry and
| software errors. Manual entry errors are by far the most
| common, and seem to be symptomatic of confusing UI and a lack
| of validation on input (easy to mistakenly put an extra 0 in a
| number field, not doing a checksum on an account number, no
| regex on a national insurance number)
|
| That said, calculation errors do happen. When furlough was
| brought in, lots of payroll softwares struggled. We think part
| of that could have been avoided with better testing.
| lentil wrote:
| > many payroll softwares will test decently
|
| That's certainly the impression I got from working in this
| field for a while. I've worked on one of the products on that
| list of UK payroll providers, and it has one of the most
| extensive test suites that I've seen. And some of my
| colleagues there had previously worked for its competitors,
| and they mentioned similarly good test coverage there.
|
| I'm sure the quality & amount of testing varies a lot between
| different products, and I have to imagine there are some
| dreadful ones. But at the same time, I don't think having
| thorough test coverage for this type of product -- especially
| for the parts of the product that deal with monetary
| calculations -- is particularly _unusual_ either.
| tebbers wrote:
| Awesome, bookmarked for the future when I have HR needs :D
| 4thstreet wrote:
| nice one, hopefully we can help you out one day :)
| fillskills wrote:
| LOVE the website design. Fresh, FAST and easy to understand.
| Kudos on the launch.
| mkrishnan wrote:
| Couldn't agree more - "Fresh, FAST and easy to understand"
|
| wish everyone could this.
| turkeywelder wrote:
| 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
| 4thstreet wrote:
| Hello, thanks for the kind words!
|
| It is indeed tricky, but in a meticulous way. I wouldn't claim
| that we're doing anything truly hard like quantum computing or
| predicting the weather :)
| 3dbrows wrote:
| > "butt" is a feature in payroll land
|
| Cloud-to-butt extension? :D
|
| Great initiative; UK payroll systems are indeed a mess. Wishing
| you the best of luck - you clearly have the skills and experience
| to make a success of this clear gap in the market. I'm familiar
| with Monzo's engineering and cultural standards, and hope you
| carry those to this startup too.
| painroll wrote:
| 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!
| 4thstreet wrote:
| 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
| 4thstreet wrote:
| just noticed your username :D thank you for the kind words!
| jonatron wrote:
| I assume there's no definitive list of all the quirks and edge
| cases involved. Will you have to rely on customer reports where
| you're missing a bizarre edge case like [making this up] a person
| with a mononym wants to use the cycle to work scheme?
| 4thstreet wrote:
| 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.
| [deleted]
| epicureanideal wrote:
| Anything to reduce the number of people working in HR is a good
| thing. They're a plague on the industry and on society.
___________________________________________________________________
(page generated 2021-07-14 23:01 UTC)