Reply to: Inside IR35 and R&D

[WordIsBond]

The business needs something so the project has to ask 'How do we do this'. The solutions options document is then produced. That's not R&D. I know the situation you mean about R&D popping up for a few hours in a project but this just isn't R&D in my mind. You may have to create something using existing methodologies or code and it's definitely a solution to a problem, but R&D?

You're right, that's not R&D. R&D is when you have no existing methodologies or code, and an expert couldn't tell you how to solve this problem. There's no clear literature telling you how to do it, so you have to devise a solution. That solution may use existing methodologies but it will combine them or implement then in a novel way which constitutes a real technological advance -- as far as you know, no one has ever done it before.

[WordIsBond]

Interesting. So, to get a feel for this, without giving too much away, are we talking about: 1) a new model structure; 2) a novel application of an existing model structure to a new area; 3) an application of an existing model structure in a way that overcame some novel computational challenges; 4) an application of an existing model structure to a new application/dataset in a similar way to other applications.

So, I thought about this for a while. We did #4, but it required #2, which couldn't actually be done without #3. And if that's not clear, and it isn't, I probably don't want to take it further anyway. But most of the #4 part of the work we did not classify as R&D, it was really only #2 & #3. Even #2 alone might not have qualified. Certainly it has been talked about in industry circles but no one has ever been able to do it (as far as we know, someone might have internally), because no one had ever solved #3. The real difficulty was getting the computations to work fast enough to be useful and deliverable before the whole market has changed and your numbers are useless. That required some outside the box creativity. There certainly wasn't any literature to which we could look and say, 'We can do that,' and there was literature we could point to that discussed the difficulty of the problem (#3), and why #2 had never been done. That put us in R&D territory.

I'm guessing it has to be something that someone working in the area could broadly point to and say, "oh, that's new", whether that is due to the model structure or the way the parameters are estimated computationally or whatever.

That's the essence of it as I understand it.

If you go AA you can discuss projects very specifically with them for, I think, two years, as to whether they qualify as R&D. That makes it very easy and because you'll have discussed exact projects on which you are working you'll quickly get a feel for how other projects would fit, or not.

[northernladuk]

I was told if you ever reach the point where you stop and say, "How can we do this?", and the answer is not readily available and not found by reading experts, you may have entered into R&D territory. Once you have an idea to solve it and you are trying it, you are still in R&D territory. That may include not only coding but also testing, including constructing a test / test data. But once you are past that point you aren't in R&D territory anymore.

So R&D can pop up for 1-2 hours or more in the middle of a much larger project that isn't R&D, or you can have a large project that is all or mostly R&D.

If the client isn't telling you how to code, it is possible that you could hit an R&D situation of which they know nothing, in the middle of a project which they aren't classifying as R&D at all. But I would guess most programmers are not going to be doing RDEC work unless it is as part of a larger RDEC project -- like the people who coded the model I mentioned above. Technically, it doesn't matter whether the client makes a claim or not if you are actually doing RDEC. Practically, if the client doesn't view the project as R&D you better have a pretty good argument, if you are ever challenged.

For those of us with foreign clients, I believe RDEC can apply to projects for them as well, but I've not asked that.

Well I'll probably have to duck out of this thread and leave it to you that has already had AA and is a lot more knowledgeable because that could cover most business requirements that don't need an off the shelf package. The business needs something so the project has to ask 'How do we do this'. The solutions options document is then produced. That's not R&D. I know the situation you mean about R&D popping up for a few hours in a project but this just isn't R&D in my mind. You may have to create something using existing methodologies or code and it's definitely a solution to a problem, but R&D? Can't see that. That would mean the scope of R&D spans high end engineer/electronic/pharmaceutical work to break new scientific ground down to writing a bespoke app for a business requirement.

It would be quicker to ask what isn't R&D in the coding world. No new product has been produced, no scientific advancement, no resolution of scientific or technological uncertainty etc.

EDIT : So. I found a really useful link, but I guess you've already seen it.

CIRD81960 - Corporate Intangibles Research and Development Manual - HMRC internal manual - GOV.UK

That seems to sit much more in line with what I am thinking and it goes a long way to explaining in detail what 'uncertainty' is and puts some more context around 'How do we do this'. Neither of which stand up very well according to that doc and it totally covers all my examples.

I wish I'd found that link before the past discussions on R&D as it would have quickly cleared up all of them.

[jamesbrown]

I'll give one example I discussed with AA. It was a type of financial modeling that, as far as we know, had never been accomplished. I designed it, my staff coded it, client staff ran some numbers and crunched them, I looked at results to suggest adjustments to the model, etc. Most of this was R&D, because you simply don't have a model without any of it. We didn't know that we could get a model that actually gave reasonable predictions, and we didn't know we could make it fast enough to be usable. So there was obviously uncertainty. Interface coding on this project was not R&D, but sufficient data work to inform the model for testing purposes, and the coding of the actual modeling, was R&D.

Interesting. So, to get a feel for this, without giving too much away, are we talking about: 1) a new model structure; 2) a novel application of an existing model structure to a new area; 3) an application of an existing model structure in a way that overcame some novel computational challenges; 4) an application of an existing model structure to a new application/dataset in a similar way to other applications.

I'm assuming it's somewhere in the space of (1)-(3). Just trying to gauge what an "uncertainty" looks like here, because pretty much everything in modelling involves resolving an uncertainty, and uncertainty may be an explicit part of the modelling (), without being particularly novel. I'm guessing it has to be something that someone working in the area could broadly point to and say, "oh, that's new", whether that is due to the model structure or the way the parameters are estimated computationally or whatever.

[WordIsBond]

Indeed. It would appear to be the silver bullet.

Question from me. In WiB's case the client is classing their work as R&D and down the chain WiB can claim RDEC. What if a contractor believes he is delivering a piece of work that meets the criteria but the client isn't going down that path. Can the contractor still go ahead or does the overall piece the client is delivering have to declared as R&D?

I was told if you ever reach the point where you stop and say, "How can we do this?", and the answer is not readily available and not found by reading experts, you may have entered into R&D territory. Once you have an idea to solve it and you are trying it, you are still in R&D territory. That may include not only coding but also testing, including constructing a test / test data. But once you are past that point you aren't in R&D territory anymore.

So R&D can pop up for 1-2 hours or more in the middle of a much larger project that isn't R&D, or you can have a large project that is all or mostly R&D.

If the client isn't telling you how to code, it is possible that you could hit an R&D situation of which they know nothing, in the middle of a project which they aren't classifying as R&D at all. But I would guess most programmers are not going to be doing RDEC work unless it is as part of a larger RDEC project -- like the people who coded the model I mentioned above. Technically, it doesn't matter whether the client makes a claim or not if you are actually doing RDEC. Practically, if the client doesn't view the project as R&D you better have a pretty good argument, if you are ever challenged.

For those of us with foreign clients, I believe RDEC can apply to projects for them as well, but I've not asked that.

[WordIsBond]

Yes, it's resolving an uncertainty.

Discussions with Advanced Assurance were very helpful because I could give specific examples, and that really helps you get a feel for it. Maybe this will help a little.

I'll give one example I discussed with AA. It was a type of financial modeling that, as far as we know, had never been accomplished. I designed it, my staff coded it, client staff ran some numbers and crunched them, I looked at results to suggest adjustments to the model, etc. Most of this was R&D, because you simply don't have a model without any of it. We didn't know that we could get a model that actually gave reasonable predictions, and we didn't know we could make it fast enough to be usable. So there was obviously uncertainty. Interface coding on this project was not R&D, but sufficient data work to inform the model for testing purposes, and the coding of the actual modeling, was R&D.

The model (we did succeed) then needed further data over an extended time period, to be fully operational. That further data work was not eligible -- the uncertainty was gone from the project by that point. I was then asked in a few months later for a mini-project to tweak the model to account for certain market conditions we hadn't considered originally. Technically, it could have been included in the first cut and if it had I'd have probably included it in the RDEC claim, since we didn't know on the first cut that it would succeed. But it was my view that there really wasn't any uncertainty any longer, and that lots of people could have designed the tweak. So we didn't claim RDEC for that job.

Hope that helps a little bit. NLUK's link mostly seems to address IT advances. My RDEC jobs have been mostly advances in financial modeling.

[northernladuk]

Also, I think that's where the AA process mentioned by WiB could be very useful.

Indeed. It would appear to be the silver bullet.

Question from me. In WiB's case the client is classing their work as R&D and down the chain WiB can claim RDEC. What if a contractor believes he is delivering a piece of work that meets the criteria but the client isn't going down that path. Can the contractor still go ahead or does the overall piece the client is delivering have to declared as R&D?

[jamesbrown]

Also, I think that's where the AA process mentioned by WiB could be very useful.

[jamesbrown]

I've never really got my head around this, particularly using that definition alone. I've had plenty of discussions with people who's definition of uncertainty would mean that anything but a straight SaaS service would count. Most recently was someone arguing customisation to Manhattan WMS was resolving uncertainty as they thought the business ask was not straight forward and they didn't know if it could do it so they spin up a PoC to prove it and they've resolved uncertainty. That's way off the criteria in my mind. That's just using code to produce an outcome, not resolve uncertainty.

Articles like this, I believe, blow their argument straight out of the water but some people just won't have it.

R&D Tax Credits | What software projects qualify?

Give that to, say, the Manhattan example and they can still pick a few bullet points to make their case.

IMO it's a very grey area but then I'm not a coder so I probably have a very different view on it.

Right, it's definitely a grey area.

Aside from taking advice, I think the best you can do is to document the hours worked against specific things that qualify, in theory (which is itself a cost that needs to be stacked against the relief claimed). Without documentation, you may have a hard time justifying a claim on request.

[northernladuk]

Thanks again. Will need to look into the definition of R&D, but I recall that it involves resolving an “uncertainty”. I may be making conservative assumptions there too (was mainly thinking of stuff that would be publishable, whether or not it could be published, but the bar is probably lower than that).

I've never really got my head around this, particularly using that definition alone. I've had plenty of discussions with people who's definition of uncertainty would mean that anything but a straight SaaS service would count. Most recently was someone arguing customisation to Manhattan WMS was resolving uncertainty as they thought the business ask was not straight forward and they didn't know if it could do it so they spin up a PoC to prove it and they've resolved uncertainty. That's way off the criteria in my mind. That's just using code to produce an outcome, not resolve uncertainty.

Articles like this, I believe, blow their argument straight out of the water but some people just won't have it.

R&D Tax Credits | What software projects qualify?

Give that to, say, the Manhattan example and they can still pick a few bullet points to make their case.

IMO it's a very grey area but then I'm not a coder so I probably have a very different view on it.

[jamesbrown]

Thanks again. Will need to look into the definition of R&D, but I recall that it involves resolving an “uncertainty”. I may be making conservative assumptions there too (was mainly thinking of stuff that would be publishable, whether or not it could be published, but the bar is probably lower than that).

[WordIsBond]

For example, I have one ongoing project that spans two accounting years (fixed price, but roughly 10-20% of my time), which is pure R&D - start to finish

Let's say you use a salary of £8K and pension contribution of £15K, no relevant travel or software. That's 23K applicable expenses, 20% of that is £4.6K. 12% is £550. Hardly a game-changer for your business, but if you have other RDEC stuff in addition to this one it starts to add up.

Once I realised how this thing works and began to think about it, I recognised that a very large percentage of my time is RDEC. That's why they bring me in, often, is to figure out stuff that no one in house can. Code implementation, more often than not, is done by my employees, their employees, or a subcontractor. If it weren't R&D they'd usually get someone cheaper than me to do it. Last year, 38% of my time was R&D, and I made larger pension contributions.

If you go this way and you have a year that has a higher than normal R&D percentage, you might want to shift as many pension contributions into that year as practical, to increase your staff costs in that year and thus your credit.

[jamesbrown]

.

Fantastic, thanks.

When I do R&D, it's often pure R&D for a specific project among several parallel projects, where the others may be much more applied (D only). For example, I have one ongoing project that spans two accounting years (fixed price, but roughly 10-20% of my time), which is pure R&D - start to finish - but that type of work is very changeable from one year to the next - OTOH, that is surely the nature of R&D anyway.

Great tip on the AA stuff. Will definitely check that out - thanks again

[WordIsBond]

BTW, OP, any recommendations on good sources of advice for RDEC or are you going this alone?

I do a lot of R&D but have never bothered with the SME scheme because I mostly team with other companies on bids and subcontract on larger projects and, for RDEC, I thought you couldn't claim more than the PAYE/NIC of the R&D staff doing the work, which is a pretty high bar for a director drawing a small salary. But now I'm wondering if my assumptions are correct...

As I mentioned, we have a fairly large project running that qualifies for the SME scheme. It's an employee doing most of it so the claim is substantial. But anyway, we went with Advanced Assurance, and my contact with HMRC encouraged me to claim for RDEC on some of the other stuff I do for clients. Obviously everything goes through my accountant but the Advanced Assurance contact is my best source of information.

They have a nice little leaflet on R&D as well. Has a lot of useful information.

It's not really that hard to claim and the RDEC stuff took out about £3K of my CT liability last year, so it's worth it (our SME claim was considerably more). Obviously, if it were just PAYE/NIC it wouldn't go very far, unless you are spending most of your time on R&D, but you probably aren't, and it is pro rata for the year. One thing to consider -- depending on how much time you spend on R&D, it might be worth paying higher salary, at least up to the personal allowance. You pay EENI and ERNI on an extra £4K, save most of that back on CT, and then save even more on the CT because of the R&D credit. I don't know the exact figures but I'd guess if you spend more than a quarter of your time on R&D it would be worth it.

The big thing you are missing is pensions. If you are making significant pension contributions those also qualify for the credit. If you use any expensive software in the R&D, that also applies. Those details are in the leaflet I linked to. In my case, pension contributions exceed salary, and it makes a nice boost to the credit.

Finally, depending on circumstances, some travel expenses may be eligible. In our case, there has been some that applies. There's several examples here: CIRD83200 - Corporate Intangibles Research and Development Manual - HMRC internal manual - GOV.UK. Bizarrely, for the travel costs to apply, the staff member must pay them personally and be reimbursed. I don't know why that is and I don't have documentation I can point you to that states it, but both the HMRC Advanced Assurance liaison and my accountant said the same thing, so I guess it must be so. I always have MyCo pay travel expenses but we make an exception if the trip is required for an RDEC job, which has happened a couple times. In those cases, I've paid personally and reclaimed it from MyCo.

That's about all I have to give you. The Advanced Assurance people seem very nice, very helpful, very clear. Best department of HMRC I've ever encountered, by far. Maybe I really should ask them about this. If you've never claimed R&D before, and you have a job of any size that you think would partly or mostly qualify, I'd recommend the AA route. It's not adversarial at all, they want to help you claim it if you are eligible.

[jamesbrown]

BTW, OP, any recommendations on good sources of advice for RDEC or are you going this alone?

I do a lot of R&D but have never bothered with the SME scheme because I mostly team with other companies on bids and subcontract on larger projects and, for RDEC, I thought you couldn't claim more than the PAYE/NIC of the R&D staff doing the work, which is a pretty high bar for a director drawing a small salary. But now I'm wondering if my assumptions are correct...