Hacker News Reader

> the answer is technical inertia (or technical debt, if you will)

One of the issues. There are number of others. For example, VAT is a value-based tax. A VAT cut gives the biggest savings to people who spend the most. Since wealthier people typically spend more, they would save more money in absolute terms. For example, a family with a food budget of 3,000 kr. would save 300 kr., while a family with a food budget of 8,000 kr. would save 800 kr. Politically, some parties might prefer tax breaks that focused on lower-income groups.

Another issue, will the cost savings actually be passed on to the consumer?

Hmm. You say "tax break" but I could argue split VAT results in the opposite: a hike in consumption tax. The base VAT rate can be set higher if the VAT on desirable consumption is lower. I.e. it's not that rich people pay less tax for books -- it's that rich people pay more tax for non-books!

Denmark already has one of the largest VAT rates in the EU (25%) - only surpassed by Finland (25.5%) and Hungary (27%). (I guess you may also argue that those two countries have reduced rates and that proves your point!)

VAT can be considered a regressive tax because the poorer I am, the more of my money I spend on goods and services, and the less on savings and investments. As a proportion of income, poor people spend more on VAT than rich people. I think it’s about double, in the UK. So you’re right that cutting VAT helps richer people more in absolute terms. But in terms of of quality of life it helps poorer people more.

[edit] assuming we’re talking about VAT on things that everyone buys. Which is why tax codes often exempt essential items from VAT.

Give people as a whole more money and they can spend it on housing. Given the decades long supply problem with housing it simply means rents increase to fill the void.

You can do both, in that you can have a system where if you make less than X, you don’t pay VAT on certain things, or less.

California is now doing this for electric car rebates. Only works for items pinned to a person.

This can easily be compensated for by simply giving the poor more rebate on income tax.

I was under the impression that VAT taxes are considered to impact mostly the poor. While in absolute terms the rich are impacted most, in percentage terms VAT is considered a much smaller portion of expenses for the rich than the poor. I quote: "VAT is a regressive tax, putting more burden to the poor than to the rich. Indeed, VAT applies the same rate to everyone regardless of their level of wealth – but the richer you are, the lower the proportion of your revenue goes to consumption."

In the U.K. most living expenses are don’t get charged vat, or get charged at a low rate - food, rent, public transport are vat free, electric, gas are low rated.

I find this logic extremely flawed. If you save half, you save half. If someone saves a lot more than you as a result, it mains they paid a lot more before, and is still paying a lot more than you now. As fair as it gets. Those that complain are usually imagining a robin-hood esque system where the tax progresses towards 100% as income goes up.

Trying to heavily tax billionaires is one thing, but the issue with them is tax avoidance by virtue of these complicated systems, and a lot of the incremental taxes land on people just plain working their ass off, getting no sleep, high stress and high blood pressure as a result. If someone has more because they worked more, they're entitled to exactly that.

Incremental tax also means that if you have a good year and a bad year you pay way more tax than if you just had two average years. Not to mention that such complicated tax is what enables tax optimization whereby those higher up can end up paying less tax. It's stupid.

Worth noting that controlling consumption via extra/less tax on specific products is debated a lot in Denmark. Namely cigarettes have a high added tax (about 2kr/0.3 usd PER cigarette). Increasing the tax and thus the price of cigarettes had a fairly large effect on consumption (0.13-0.82% less cigarettes consumed for every 1% price increase) [1]. Recently it has been debated to remove the VAT from vegetables and fruit to increase consumption of those.

The same logic is used for this book VAT exemption (which is good in my opinion) - I doubt we'll see the same effect though. Young people not reading is a complex problem to solve but books are really expensive to buy, so it's a good place to start.

[1] https://vidensraad.dk/sites/default/files/node/field_report_...

Note that while you have 25% VAT on things, actual VAT accounting is fully dynamic and banking and accounting systems handle this just fine.

On the incoming side, bills can come from other countries with an entirely arbitrary VAT value, so there the VAT value is recorded from the bill.

On the VAT refund side, arbitrary values are used even for Danish VAT, as companies can get full, fixed fraction or even entirely variable fraction if VAT refunded. For example, a company dinner can only be partially VAT refunded as you had private benefit of food, and VAT refund of an asset like a van is the set by the ratio of intended company vs private usage.

On the outgoing side, most banking and accounting systems would be prepared for other EU countries.

There's definitely going to be something hardcoded somewhere (including over 9000 times in the tax systems themselves), but the point is that VAT is already a dynamic size.

Insane that technical debt and general incompetency in software can produce such unexpected side effects.

Why the general incompetency added on?

Ad the other commenter wrote: The 25% is assumed - this has nothing to do with competence but to what level an assumption is true.

Everybody can point fingers at 25 year old code and call the developers incompetent because surrounding requirements have changed.

Considering that's 25 year old code I'd expect at least a

  #define VAT 0.25

and not hardcoded values all around the source code. However I don't expect a table (db table, array, etc) of product categories with their own VAT code or a user defined exception list. That extra code would inevitably add bugs that are not worth the trouble. Adding an exception for books probably requires an update of the apps.

VAT is not a compile-time value. It's a runtime value. Nevermind not scattering it in your code, it shouldn't be in your code at all.

VAT rate can and does change. As such it can be different on different dates. And this change might not even correspond to change of year. So it really has no place in code.

The US is used to this as the rate changes between states and product categories - it is not reasonable to adopt this view onto other VAT systems.

You can not transfer categorical statements like you do.

Such a constant would be no better -- they don't want to change the VAT rate across all product types.

The code missing is that for per-product type variation in VAT rate, which sounds complicated enough that Iawould expect a good engineer to shrug and say YAGNI until it's actually necessary.

> and call the developers incompetent

Why would you blame developers for this?

This is management problem!

That general incompetency you're referring to there can also be worded as

For years they didn't build unneeded complexity. And it sounds like for many more years to come. So they're just efficient. Any developer will have had to make things configurable afterwards, that's fine, just evolution of code.

Hard coding also means that it's less likely to break. No customer (in Denmark) can influence this, so why make it configurable?

Over time this does become a problem when source code is lost/companies go under.

So if the House introduced a 'fixed' VAT tomorrow, say $1, not proportional to the price of the product, would that not break most software used to compute VATs?

We have to make assumptions. Good software doesn't account for every future possiblity, but it is easy to change when the requirements change.

During the financial crisis, Ireland added half a percent to VAT. Wanna guess what happened?

(The funny thing is, the _reduced_ rate had been 13.5% for years, but a non-integer rate for the main rate _still_ caused widespread IT problems...)

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)

* an assumption of the inertia of law

* general incompetence/naivete

???

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.

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?

Now VAT is 12% on Tuesdays. Did you "hard code" that VAT is constant across weekdays? The naivite..

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.

The cheif/over-engineerer will account for variable tax rates in the future, especially if they plan to sell their erp system in other countries.

Not only that, but this person will account for arbitrary VAT schemes and embed a small, but Turing complete, dsl to calculate the vat rate.