What is the primary reason for hard-coding these kinds of things? Gotta imagine CScientists would have debated this during the design phase. I have some hypotheses, are any of these right?
* correctness/verifiability analyses
* security? in compiled tools (prevent malicious re-configuration)
The real problem is actually less the exact rate of 25%, but rather that most of the systems only assume one rate. Denmark was the first country to introduce a general VAT in 1967, and whilst the rate has changed (last in 1992 to 25%), the number of rates have not. So lowering the general VAT rate would likely be possible in a 1-3 year time frame (depending on unknown factors), but lowering the general VAT rate would be a significant loss on state finances (thus not interesting to politicians) (and as someone else pointed out, it mostly favours high spenders, which is also politically dicey).
However, introducing a split rate would definitely require a time frame of at least 4 years, and no politician are willing to wait that long for a politician win.
> The real problem is actually less the exact rate of 25%, but rather that most of the systems only assume one rate.
This can’t be the case.
You have to apply the VAT of their own country to customer from other part of the union and some services are exempt.
In all likelihood, most systems in Denmark already supports using different VAT for different products. Plus, most accounting systems won’t be Denmark specific anyway but simply configured for it.
Can someone explain to me why I do sit at -2 on a perfectly factually valid comment? Is VAT so foreign to American they are actually lost by how intra-community purchases work and how VAT is collected? Are the Danes here simply never exporting anything?
There's absolutely no reason to hard-code the value. That's just bad programming.
However you can't expect programmers to predict all possible future compatibility.
In my country VAT has a current rate. That rate can, and has, changed. But we have one rate. Some goods are exempt, but products have a VAT yes/no field.
Perhaps in the future the system will change. One possible change is that VAT attracts different % for different products. I'm not predicting that, or coding for it now. VAT rules could change to anything- I can't code against that.
Imagine the complexity of correctly accounting for a VAT when rates vary dependin on product type -- and doing it across an entire national economy! I'm glad they don't support that for as long as they don't have to.
Is it doable? Sure. Does it need resources that could be more fruitfully applied elsewhere? Probably.
Funnily enough only EU country with no reduced rates on some products is Denmark. So pretty much any system used in other countries already takes this in account.
* correctness/verifiability analyses
* security? in compiled tools (prevent malicious re-configuration)
* an assumption of the inertia of law
* general incompetence/naivete
???