Comment by painroll | Hacker News Reader

Comment by painroll | Hacker News Reader

Parent Full thread

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!

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

> It's not done per month, but based on the amount you've paid so far this year.

Does this mean you get paid more at the beginning of the year than the end?

Not a payroll human but someone who lives in the UK.

It does not, we have various brackets that you fall into as your income rises.

- No income tax is paid on the first £12,500 of your earnings - 20% on everything between £12,500 and £50,000 - 40% on anything between £50,000 and £150,000 - 45% on anything over £150,000

The way that HMRC likes to figure it out is that you take the salary of the person in question, and then you take into account all of the above bracketing plus more little gotchas. And spread their tax over the course of the whole year as evenly as possible.

This gets more complex when you change jobs or get a new salary midway through the tax year and then payroll software has to account for that and try and even out all the payments for the rest of the year.

Hopefully that makes some sense!

It's quite complicated. Income Tax is spread over the year as the first £12k or so is not taxed, so they try to use that balance across the 12 months. We also have something called National Insurance through which eligibility for a state pension is calculated and that's calculated weekly/monthly. There are also student loan repayments, and depending on when you studied at University it changes the threshold you repay at.

just noticed your username :D thank you for the kind words!

Reply on news.ycombinator.com