While this does convey the idea, the premise is also biased.
> even though it has a total of $100K in the bank after the actual expenses were paid.
People running a business can perfectly understand the concept of liquidity. And yes, just because you transform money to something else, then it doesn't mean that you should not be taxed on it.
The extreme example is a company that buys gold on the last trading day of the year - now there is no profit! On the first day they sell the gold again and does tax eviction.
The core question is to what extend software constitutes an asset or consumption.
(Personally, I do not believe that software constitutes an asset in any meaningful way, but a practical tradeoff could be that software is a 10% asset)
I think you are conflating "software engineers" with "software". A business that pays a software engineer doesn't automatically receive working software in return, especially not in the first year. It doesn't seem fair to assume that paying a dev $200k means that the business received an asset (some code) worth $200k in return, and thus can be taxed on it as if it were an asset producing $200k in profits a year.
I am not conflating, but the law is. Obviously it would be better to have an appraisal of the software - I reckon law makers see the cost of producing ad an ok proxy.
Btw,this is how it is done in many construction projects also. Like bridges, budings, etc.
I don't know how you're supposed to value software. I just reread your original post - picking 10% out of thin air doesn't make much sense either.
Software is more like a blueprint for a building, it's not the building itself. How much is a blueprint worth? If 100 architects spent a year on it, does that mean the blueprint is worth 100 x salaries? It might actually be worth nothing, if the blueprint asks the construction team to do something impossible.
Software is even worse though, because at least with construction, there are known physical models and real-world constraints (like physics) that decide whether a design can or cannot be implemented. A piece of software written today might be entirely unimplementable and worth nothing, but a breakthrough elsewhere in 5 years might make it extremely valuable at that time
I really agree in all your points, and the the 10% would be the proposed practical middle ground - but it is neither a good model.
I don't know how to tax this.
But I can identify the issue: You can channel your revenue into a non-taxible assets that you can bring into the next accounting period tax free.
Regardless of this is stocks, bonds, gold, unsold inventory, or IP, that is not fair.
I would hope for someone to device something that is fair and easy to understand. And then I would hope for them to get it through to the politicians.
Um, so you have it so that if I hire (let’s say) bridge engineer for 100$ but he doesn’t get any materials and produces only paper model which I sell for 1$ does it mean I’m going to be taxed based on 101$ ?
andrewlgood is explaining the capitalization process in another thread under this post - I can recommend reading that.
> The core question is to what extend software constitutes an asset or consumption.
Isn't part of the problem with our industry that, even it is an asset, its value can be hard to determine even for a long time after you've written it, and it may be pretty weakly related to how much you paid to build it?
- you might have spent a lot on developers last year but next year you find out that you're the new Quibi and no one wants to use your product
- you might have had a small, tight team and what you built turns out to be hugely valuable (like instagram or whatsapp)
- ... and to the degree that the software is part of a valuable business, how do you really assign value to the software as versus the go-to-market plan, the partnership/distribution agreements, etc that helped make the business succeed?
These risks would appear to be the same as a shoe producer wanting to bring shoes to market - regardless they are still taxed on the value of their inventory.
Some of the risks are similar, but your "regardless" is bypassing the point.
We can value a real shoe pretty well. But what if we could duplicate all the shoes we built for less than a penny per pair? What would be the value of our inventory?
There are pretty established accounting rules for this.
For valuing digital goods?
Are those rules smarter than looking at the money it took to make? If so please share where I can read more.
If not, then despite being "established" the problem isn't solved.
> The extreme example is a company that buys gold on the last trading day of the year - now there is no profit! On the first day they sell the gold again and does tax eviction.
In this example, it seems like you're assuming that the revenue from the sale of the gold would not be taxable, but I don't see why that should or would be the case.
ETA: also, gold is far, far more fungible than any particular software
> The core question is to what extend software constitutes an asset
Maybe we can finally deduct all that technical debt.
If a software project fails can we claim depreciation, like after a car crash?
Well, until now you automatically had depreciation.
In the future you will still get it automatically, just deferred.
You have the same, automatic deferral, with cars.
But if you're in a crash, and it's a total loss, you can depreciate faster, which is helpful because you might need to buy a new one.
So, since they're assets, can we write off software projects that fail?