Inside IR35 and R&D

[jamesbrown]

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

[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?

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

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

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

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

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

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