4thstreet

Interesting! Can you share any insight into how your ML algorithm works?

Hi! If I understand correctly, you're working for a foreign company but living in the UK and hoping to go on UK payroll?

We support UK payroll, but there's a few other hoops your company may have to jump through in order to employ you in the UK.

Things to be aware of are whether your work in the UK will trigger "permanent establishment", which could have corporation tax implications for your company.

If your employer has a UK entity we can support them, but if not you might want to suggest a Employer of Record setup to which will abstract away a lot of compliance headaches for your company (e.g. https://www.letsdeel.com/ , https://www.boundlesshq.com/ , https://remote.com/)

Hope that helps!

For the all-in-one HR & payroll product, we're targeting startups in the 0-50 person range. Part of that is pragmatism: as a young company smaller startups tend to be discerning early adopters who we can easily relate to as a small startup ourselves.

Initially we did wonder if we could sell it back to Monzo, but I think that's a way off - supplier onboarding requirements alone make it hard for a new player to sell to a large company (especially banks, which typically are demanding with supplier onboarding).

Thanks for the thoughts on the API!

The API is something we're exploring alongside the all-in-one HR & payroll product.

With the API you get much higher volumes for a lower price. It's mice vs. whales! See here for what I'm on about: http://christophjanz.blogspot.com/2019/04/five-years-later-f...

As far as how well financially one model turns out to be vs the other, I think a lot of that depends on market size. I do wonder how big the market is for a payroll API. Though we've come across some interesting applications (employer of record companies, accounting firms, hr products etc).

The cool thing that I've always liked about API businesses, is that it's like building really fertile ground for new things to arise that don't even exist yet.

Interesting to think about what new modals could bloom over a fully-featured payroll API

Interesting to hear your experience, thanks!

I really like the product Pento are building, interested to hear how robust the HR syncing proves to be. Sounds like it's going well for you?

No way, and now I can't edit it haha

I really should turn that off...

Aw thanks - hearing that makes me disproportionately happy :D Was inspired by https://pry.co/, so props to them!

nice one, hopefully we can help you out one day :)

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

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 :)

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

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.

> 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.