Programming

Who hard-coded the VAT?

With the recent change in UK VAT rates there has been an intriguing chance to see which retailers have a decent data model and those who just assumed that VAT would never change.

If you look at your receipt then the companies that have a decent data model will probably just have a very ordinary looking receipt. Maybe if they are showing off then they will have a little message telling you the current rate.

However the companies that have a bad data model will have an additional line on your receipt that reads something like “VAT Discount” that subtracts 2% from your net bill. This means they have happily hardcoded the VAT rate throughout their system in the mistaken belief that it was a constant, like gravity.

In fact, so mild have the economic climes been recently that it seemed a reasonable assumption. I used to work on a retail system and while we did correctly data drive the VAT rates the data model had no way of tracking the change in VAT rate over time. If we changed the standard VAT rate it would also change it for all historical invoices prior to the switchover. For this reason when an invoice line was calculated the VAT also had to be calculated and written at the time order was finalised. It was obscure but the VAT rate was always the current rate and if you wanted to figure out the historical rate applied you had to do the work yourself.

Who would think that such a simple tax would cause such problems? Or allow you to see so much of the internals of big firm’s systems?

Standard

2 thoughts on “Who hard-coded the VAT?

  1. Drive by Commenter says:

    Isn’t this a classic case of “your mistakes are idiocy, mine are forgivable”? 🙂 Out of the people putting “VAT Discount” on a receipt, how do you know which of them assumed VAT was constant like gravity, and which of them did 99% of everything correctly, and then when it came to rolling out the change across a large, complex production system, discovered a bug in a minor or 3rd party system that prevented them from implementing the change in the “correct” way?

  2. You’re right, I don’t know the reason why but I do know that you should be able change the VAT rate at every Budget at least. So everyone who hasn’t been able to change cleanly has been guilty of making some form of invalid assumption. I assume the most common issue is indirectly linking Standard Rate VAT with a value of 17.5% but I would love to hear more from people trying to deal with the issue.

    I didn’t design the system I worked on but I do give it some credit for dealing with this situation correctly. It would have been great to have a time-series VAT rate to allow us to retroactively recalculate invoices and make refund credits easier but at least you didn’t have to hack a discount just to account for a tax rate change. A “large, complex production system” for retail that doesn’t even generate invoices correctly is a large, complex and broken production system. It neither a mistake not idiocy, it’s just broken.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s