VAT on e-Services — Where accounting, tax and systems don’t quite meet.
You might be aware that SARS are broadening the net on VAT on imported ‘e-services’ this month (April 2019). Effectively they’ve be broadened the classification of e-services, as per the legislation at least, to be more inclusive.
Why? Well, in short the previous definition didn’t technically include services such as cloud computing and as a result, companies like AWS, didn’t levy VAT on certain services being sold into South Africa.
Pre 2014, the onus lay with the consumer to hand over VAT on imported e-services via a reverse charge mechanism. This was one of those rules that while looking okay on paper didn’t really hold water since it was pretty onerous on consumers and was one which SARS couldn’t really police very well.
Due to this, the onus of declaring and paying over VAT on these services was moved from the consumer to the suppliers of e-services into South Africa, thus moving the onus from the many to the few (relatively speaking)- which I guess is a good thing.
What does this mean?
Well, first off, if you use services such as AWS and you’re not a VAT vendor, prepare to face a price increase of 15% on these services.
Secondly, if you are a VAT vendor, you’ll need to ensure that you claim the deductions available to you going forward to ensure you don’t end up out of pocket.
Now price increases aside, there’s still a pretty frustrating issue here which, while not new, will become more prevalent with this change. It’s also something I don’t think many people notice. The route of the problem comes from the fact that many of these services are billed for in foreign currencies and the systems we have in place don’t cater very well for the implications of this.
The simplistic views of how VAT on these transactions work looks something like this:
The problem is, the reality of the situation looks more like this:
AN ISSUE FOR SARS
The problem here is that the correct accounting for these transactions and their VAT becomes quite messy. In the example above, unless there is manual intervention in the recording of the transaction, the VAT input claimed by the local business will end up larger than the Output submitted by the foreign supplier. This leaves SARS out of pocket because the exchange rate you get from your bank on your credit card (“CC”) payment is typically worse / more expensive than the one applied by the supplier. As a result, it’s not only an issue for the unfortunate bookkeepers who have to deal with this manual intervention on an increasing number of transactions but SARS as well.
SOME CHEEKY BANK FEES
If you’re wondering what FCTF stands for in the image above, it’s ‘Foreign Currency Translation Fee’ — most banks in SA will charge you this fee when you’re making a payment in foreign currency from your CC and it’s usually in the range of 2 -3% but you can check your banks pricing doc’s to find out. It does feel like quite a cheeky charge since there appears to be a margin built in to the exchange rate they offer you but that’s neither here nor there. The issue I have here is when this charge is lumped in with the transaction on your bank statement (in one line item) as this further obfuscates the transaction. And yes, I have seen this happen.
Another issue arising from this is that of what we post to our foreign exchange (“FX”) gains/losses accounts. In order to correctly account for the VAT on the transaction in example two, one generally has to post a resulting VAT-free amount somewhere.
AN ACCOUNTING ISSUE
This ‘somewhere’ is most likely to be ones FX gains/(losses) account. Now when you’re paying for a service received over time in a foreign currency, the theory is that one records the expense at an average rate over time and then pays at a point in time (at a different rate) resulting in an FX gain/loss. This generally doesn’t happen in practice for small transactions over short periods of time for practical reasons. The issue is that the amount getting posted to FX gains/losses here isn’t the same thing. In the example above there is a difference at a point in time, the payment occurs immediately and there is no exposure over time i.e. even if the average rate over the service period and the rate upon payment payment were the same, we’d still end up with a gain/loss. Your bank will also not provide you with an invoice for the differential amount - how could they, they don’t have the information to know what it is.
As a result we have somewhat of a mismatch between what is theoretically required by the accounting standards, what is required from a tax perspective and what our current systems can practically achieve.
I appreciate that ‘issues’ described above are not particularly material and most people won’t pay them much heed. My concern is that as a result of this there’s less incentive to improve the situation. To my mind, between tax authorities, those setting accounting standards and industry, we need to do a better job at setting the playing field for businesses in such a way that doesn’t involve un-necessary complication and wasted human capital. It’s really just not good for business.
Sales taxes have been around for a very long time and the idea behind them is pretty simple. Unless we’re proactive however, I fear that the way they’re administered and collected is likely to become more and more troublesome as time goes by and our economies become increasingly digital.
Not being a fan of criticising without being constructive, I’ll follow this up with some thoughts on interesting possibilities for the future of sales taxes & how me might address some of these issues.
If you’ve managed to find that elusive silver bullet to any of the frustrations I’ve described, please, feel free to share.
