The answer to all these questions is yes, i don't see the point in trying to obfuscate this with artificial complexity.
What about HR, etc who use excel documents?
IF they are using it rather than developing it, no. If they put in 5 hours a week writing code, yes for those 5 hours. This isn't hard.
Okay so your random HR person at a nontechnical small to medium sized business now is on the line for developing spreadsheets to manage scheduling.
OR they need to maintain a set of activity codes and a timesheet outlining how many hours (or partial hours) each week are spent on what types of tasks.
It's unnecessary complexity if you want to be in actual compliance with the tax code vs just guessing whether XYZ task is on one side of the line vs the other and hoping it doesn't come back to bite you later.
How is an HR person writing a script to do their HR work better considered an R&D expense?
Scripted automation is quite literally development of IP. It's an asset that belongs to the company and will be counted as such on its balance sheet.
What if they literally just write a post-it note of how to perform certain actions? Are those 5 minutes capital investment? The information on that scrap of paper is subject to copyright and is a company asset in just the same way as a script. Where do they draw the line?
Anytime someone has a good idea, it should be depreciated over 5 years? Why is software special? It is all just the composition of simple machines.
I'm pretty sure it's because other industries wondered why they were having to spread such costs over 5 years while software firms were able to write them all down at once. It's not that I have a strong opinion about this either way (I'm not running or employed in a business where this matters), but that ultimately this is a philosophical argument. There isn't an objectively correct way to do this, how you view it is down to what your economic interests happen to be.
It's the other way around. Software used to be special, in that money the company spent to improve its internal processes by, say, buying a calculator had to be amortized, while money spent on developing software automation were not.
So now every engineer has to record how many hours each day were spent doing "software development" vs. "software maintenance"/"overhead"/"etc..."?
You just add a row to spreadsheet at the end of the month. 30% maintenance, 70% development or whatever
My last company required timesheets to be submitted daily.
This is common in Canada for companies claiming SR&ED credits: https://www.canada.ca/en/revenue-agency/services/scientific-...
The word “just” in your comment disgusts me
Why?
They're suggesting you spend a minute or two per month thinking about it, not meticulous tracking.
That might not be practical, but what they are describing is a perfectly good use of the word "just".
A minute or two (or even 10 minutes) per month is basically just guessing/bullshitting. Anything that is accurate rather than imagination requires more overhead than this. Likely anything even remotely accurate requires the sort of micromanagement software that lawyers use to track billable hours, requires desktop-surveillance, and meeting minutes-dissection after-the-fact. Not sure how they will decide to rate reddit doomscrolling when tax season rolls around either, which if we're honest, is some significant fraction of our in-office hours (hell, strangely, some of that time is when I figure out the tricky stuff).
So no, "just" is hardly fair.
Government wants a number -- they get a number. How I get to the number is precise enough in my opinion and you are free to disagree with my methodology.
When I was doing it, I worked in an actual startup and granularity of time allocation was in weeks. This week I was doing the thing, the other I was mostly doing bugfixes/refactorings etc.
You could do more precise and account with hour or minute granularity with tools if you have to
> A minute or two (or even 10 minutes) per month is basically just guessing/bullshitting.
Correct, they are suggesting basically just guessing.
Which is why "just" is correct for their suggestion.
It's not a good suggestion but it really is that easy to implement.