|
|
|
|
|
by painroll
1806 days ago
|
|
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! |
|
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