The effect of Gigaba’s VAT increase on IT systems
VAT? That will never change...
This past week has seen a particular theme cropping up on certain social media platforms, which I’ve watched with some amusement. It was all sparked by the announcement made by the South African finance minister, Malusi Gigaba, regarding the proposed increase of the VAT rate from 14% to 15%. While the change still needs to achieve final parliamentary approval, it is expected to come into effect April 1st, 2018. And so, those of us in the IT world have read many comments poking fun at the developers out there who are now inevitably sweating bullets, as they remember how they hard-coded that “1.14” somewhere deep inside the source code.
The Problem
But let’s take a step back for a moment. What is the issue here? To put it simply, a thing that many assumed would not happen in the foreseeable future, looks very likely to happen in the very, very near future. A simple number, one that is so well known, so embedded in our minds that it is synonymous with “tax”, is about to change. And the issue here is that there is a high probability that many software systems out there have been written by people who allowed this variable to become a constant, first in their minds, and then in their code. They have hard-coded the value for VAT.
It seems like such a simple thing to avoid (and superficially, it is) but the truth of the matter is that most seasoned developers probably have their fair share of tales of tough discussions with clients or project managers, fighting to find the balance between meeting deadlines, and catering for edge case scenarios. Scenarios such as government changing the VAT rate by 1 percent.
The following are 3 phrases that will no doubt be eerily familiar to anyone who has been involved in software development.
- “That will never happen, let’s not worry about that”
- An easy and tempting statement to make, even when it is obvious hyperbole, but the point is clear – the likelihood of changing is incredibly low, within the timeframe that we are currently focused on, which is driven almost entirely by project pressures and deadlines. Note that this line of reasoning is very often valid and entirely necessary.
- VAT was first introduced in SA at 10% in 1991, and was changed to 14% in 1993. In terms of defining values as nearly “constant”, a 25-year lifespan could probably only be regarded as “forever” in an industry as young as IT…
- “It’s not like that changes every day, we’ll deal with it when it comes up”
- Superficially similar to above, still employing hyperbole, but with a different angle. This time we’re saying “let’s not over-engineer and spend on a solution for something that can just as easily (perhaps more quickly) be solved manually if and when it comes up”. Still similar to above, this argument certainly has its merits and its place.
- Of course, this can easily be very short-sighted and is the very antithesis of a solution able to scale with its targeted problem.
- “We read it from a configuration file/settings table, no problem!”
- Thankfully, a more common answer one can expect to hear this week, as it tells us two things:
- Firstly, it demonstrates a basic awareness of allowing for adaptation to external events through opening up parameters for change. In this example, we achieve it through a configuration file or a system setting stored in the database. Simply put, not hard-coding the actual VAT rate of “14%” in the source code as a magic string or magic number.
- Secondly, we can perhaps rest a little easier as there is evidence of at least some level of pride in the developers’ code (or at least, fear of the shame of taking shortcuts like this)
- Thankfully, a more common answer one can expect to hear this week, as it tells us two things:
Looking Deeper
Unfortunately, we need to look at this situation a little deeper. The VAT rate itself is of course just the single most visible component of this equation. One equally important variable would be the date at which this new rate came/comes into effect. The one without the other is useless. So, making the VAT rate itself configurable is seldom good enough, when one realises this rate does not operate in a timeless vacuum. Further problem scenarios emerge when we start to dig deeper. The system now needs to be able to take into account questions of precisely when the VAT calculation is performed, in terms of the internal workflows, both system and organisational. For instance, perhaps an order record is created one day, and through normal operational delays (whether expected or unforeseen being irrelevant), it is only populated with line items over the course of the following week. The order is then picked or manufactured (again, over the course of a few days or weeks), and then perhaps consolidated with other orders, and maybe its delivered a month later. Or perhaps it’s a monthly recurring order, or a staggered monthly delivery of services, and so on. How confident are you that your analysis and development teams will apply the correct VAT rate here? Do they know whether to calculate at the point of order placement, settlement, delivery, etc.? Do they know about fair apportionment in the case of recurring or partial deliveries?
Lastly, is the system storing the “right” information about each transaction? Too often, important principles or practices can become harmful if they have been applied a little too eagerly. One example here might be something called normalization in relational databases. While highly valuable for a plethora of reasons, this “decoupling” of information might conceivably (or at least, theoretically) become problematic if it becomes difficult to identify which VAT rate was used on a particular transaction. Note that in the case of a nation-wide, date-specific change like this, much of this can be worked out after the fact without too much concern, but the principle should hopefully still be apparent.
Going Forward
In many businesses the change of a single value, in this case the national VAT rate, is going to have a cascading effect through systems, and over time. Adequately handling this change and future changes like it will require the judicious facilitation and collaboration between multiple areas of expertise - internal business processes, design of internal systems, design of 3rd party interfaced systems, industry expectations, and even tax law, to name a few.
Hopefully, the challenges faced over the next few months are fewer than expected, and easily and quickly resolved. Moreover, this will in future hopefully become an object lesson to product owners, project managers, and software engineers. A team that allows itself the space to build deep insight, foster and apply foresight supported by experience, ask the hard questions, and perhaps most importantly, challenge the easy answers - this is the team that will be indispensable and invaluable. This, coupled with the willingness to learn from similar lessons in IT’s short but colourful history, is the key to confidently navigating the inevitable changes to things that will never change.
To read more about:
The VAT change: Businesstech.co.za - Why South Africans should be keeping their receipts ahead of the VAT change
Normalization: Wikipedia - Database Normalization
Hard-coding: Wikipedia - Hard Coding
Want to know more about Yellowtail Software:
Please contact us by
- sending an e-mail to info@yellowtail.co.za, or
- call us at +27 (0)21 461 4480
and we'll put you in touch with our specialists
