20% VAT rate - The Cloud Perspective

You may have already seen a similar posting in the Budget Group, but this posting takes a SaaS Cloud perspective ....

As George Osborne and the UK coalition has decided to raise standard VAT to 20% from next January, "usefully" on 4th January rather than on 1st , at least we have the chance to prepare properly for the rate change. This applies to people both in business and in practice, and to the authors and vendors of financial software.

The rate rise is especially relevant to SaaS Cloud services, both for vendors and users. Understanding clearly who is going to do what when will be critical. Users remain responsible for VAT compliance, so:

  • What will users be able to control themselves?
  • What will need to be done by the vendor, both in preparation and during the transition?.

Everyone will want to keep additional admin and/or development costs to a minimum. Given the possibility of VAT penalties, everyone needs to be careful - especially with PI implications for practising firms and others providing outsourced back-office services.

With only a few days' notice of the reduction to 15% in 2008, and the subsequent reinstatement of the 17.5% rate, I produced a series of articles then on the key system issues.

Although the increase to 20% is similar, it will be different in both the principles and practical application. I have written an article that sets out some pointers in these key aspects:

  1. Commercial impact
  2. Sales pricing
  3. Issues for software and SaaS services
  4. Additional issues for users

The article provides tips for software authors and vendors (many of the issues apply equally to on-premise packages), plus an overview for users of what to expect and to do themselves.

I'm encouraging both vendors and users to comment on how their specific software is going to cope with the rate change, which I trust will add value.

I hope you find the full article useful, whether you are a vendor or user:

Commercial and Systems Implications of the 20% VAT rate

 

Comments

A vendor perspective

Accountsportal | | Permalink

Useful article, thanks.

Some thoughts from a vendor's perspective.

I find it hard to understand how it possible to change the rate of an existing VAT code, and still process all the transactions correctly. Surely its far better to have a new rate code?

Systems should be able to cope with intra-period changes to VAT rate codes, just as they should be able to cope with intra-period changes in the VAT scheme (standard or flat) or accounting method (cash or accrual). This should be done without having to do calculate two (or more) VAT reports for a single period.

To me, the biggest single issue is centered around the user, and making sure (or as sure as possible) that users understand how to process their transactions correctly around the time of the change. Nevertheless, some will still fall through the net, and so proper procedures should be in place to get them back on the right track - i.e. how to correct the transactions that have been incorrectly entered. Some automated checks should be put in place, and exception reports created for inconsistent transaction processing.

Overall, however, I dont forsee too much systems/user pain over this. Mostly due to the fact that there was a temporary VAT rate decrease/increase recently, so most users will be somewhat familiar with a change.

John Stokdyk's picture

Interesting to see Cloud suppliers taking advantage

John Stokdyk | | Permalink

You can usually trust Duane Jackson to be quick off the mark when it comes to any good PR opportunity and his team are the first out of the traps with a release announcing Kashflow software VAT-ready.

"Within an hour of the chancellor announcing tax and VAT changes, the web-based solution was adjusted for customers,  making  KashFlow the first accounting solution to be VAT January 2011 ready." the press release states. "Changing VAT rates from the current 17.5% to the proposed VAT rate of 20% in January 2011 is a one click operation."

Duane commented: “Cloud computing means that we can make immediate changes. We do not have to post the usual messages that the system will be updated, or send out new software. Our web-based solution means that our customers are ready and running.”

Liberty and a few other Cloud suppliers put out similar messages the last time around, but as Accountsportal notes there are nuances about the best way to effect rate changes and dealing with late invoices etc. Perhaps Duane can drop by and tell us more - and I'd welcome feedback from other suppliers on the subject. As is often the case on AccountingWEB.co.uk, discussions like this can feed into articles that enlighten the rest of our audience.

dahowlett's picture

Why?

dahowlett | | Permalink

@john - why would or should Duane grace your pages with an explanation. All his customers need know is that it is taken care of. If other vendors can't figure that out then....errr....that's their problem isn't it?

cverrier's picture

Indeed

cverrier | | Permalink

I'm with Dennis.

My FreeAgent system "Just worked" for the 15% change, sorted out the Flat Rate implications as it went, and I didn't really give it a second thought.   The software still let me manually choose rates for work carried out before the change but billed after (I accepted the defaults it offered).

For all I know, the actual upgrade was very difficult and involved horrible database updates - but my SaaS supplier does all that stuff for me at their data centres, so my experience, as a customer, consisted of little more than logging in out of mild curiosity to see what had changed and then getting on with other stuff.

It was a huge contrast to a professional Practice Management product I know, which required urgent software updates and general faffing around to cope (and still got the 'continuous supply' stuff wrong for monthly direct debit clients).

carnmores's picture

of course there is a potential problem

carnmores | | Permalink

and that is people might start charging 20% now! or is the whole thing date sensitive i presume not?

cverrier's picture

Vendor issues

cverrier | | Permalink

@AccountsPortal - Having two VAT rate codes is a bit of an issue, because the rate change ISN'T two different rates - it's a change to the value of the Standard Rate.

About 30 second's thought suggests one approach - When you store the list of VAT rates (Standard, Reduced, Zero, Exempt, etc) in your system - add a date-range alongside the actual percentage figure (so you have a little table of rates for Standard, along with when the rate applies).  So then, any particular transaction's Tax Point date can be matched against the correct percentage figure.

If you are very paranoid, you could even store the actual percentage rate with each transaction, but then your database isn't classically normalised any more - and we can't have that.

Of course, I'm not a proper programmer, so there may be even sneakier solutions.

@carnmores - Absolutely it's date-sensitive.

dahowlett's picture

Don't be silly

dahowlett | | Permalink

...do you think peeps are that daft that when they bring those transactions into their own systems they wouldn't see that happening and query?

edmoly's picture

Making it look simple is hard

edmoly | | Permalink

Charles, spot on.

Also imagine when users create recurring invoices, or estimates that they want to convert into invoices, or new transactions that they want to explain the 'same' as old ones etc.

All handled seamlessly by FreeAgent (and for all I know, Kashflow and others) along with user-transparent handling of Flat Rate Scheme and Fuel Scale Charge changes with nary a VAT Rate Code in sight.

Now that - as Paul Daniels used to day (and Steve Jobs would say now) - is magic!

 

dahowlett's picture

Simple...huh?

dahowlett | | Permalink

@ed - that's why the new generation are creaming the incumbents...different mindset and bugger all to do with these kinds of pissy details...which is why you guys get paid...as you know.

Interesting discussion, but it's about software archtecture not

bryanrichter | | Permalink

This is an interesting debate, but to my mind, the way that software implements a change to the VAT code and handles some of the practical issues mentioned here is about how the software has been architected. Was the software developed to handle different VAT rates, or was it hard coded to have a single rate?

The only difference with Cloud or SaaS versus on-premise is that with the online apps, the upgrade is taken care of without the need for user intervention. With an on-premise app, the user will either have to install a new version from the vendor if the software needs to be changed, or enter a new line in a VAT table with a new value and date if the software copes with multiple VAT codes. As always, some users will like the idea of it being done for them, others will prefer to do the manual change when they are ready to. 

But it's all about the application design. Online apps can be badly designed just as easily as an on-premise app can be badly designed. Either way, it's primarily the suppliers problem and not the customer's.

challisc's picture

But always the customer's responsibility!

challisc | | Permalink

@bryanrichter Absolutely right that this issue is equally relevant to on-premise and cloud computing - but with some key differences such as those I set out in my initial posting.

As a user I need to know exactly what's going on, in advance, on issues such as:

  • Raising credit notes at the correct rate (I don't want sundry credit balances or customer-service issues)
  • How VAT reports will look when the rate changes mid-period. Is it a different code or a different rate on an existing code? Will the audit trails be clear enough to check, and submit for VAT imspection?
  • Where relevant, how VAT will be applied to sales orders (and possibly purchase orders) in progress. Does the VAT code get applied from  the customer and product tables on invoicing? Or is it pre-embedded in the order, and possibly needs to be updated? If so, how?
  • In any case do the VAT codes in customer and  product tables need to be updated at midnight on Monday 3rd?  Does"one click" mean I have to be there at midnight, or can any changes be pre-scheduled? (Especially relevant to webshops, including the household names you might be using. In fact do you have to change all the prices because they are VAT inclusive?)
  • Handling supplier invoices and employee expense claims coming in at different rates in 2011 (in Excel?)
  • Cash flow forecasting (not just the technical aspects, but how will buying patterns change over the changeover period?)
  • How VAT is handled in interfaces and APIs
  • For cloud solutions specifically, what is the vendor going to do, and what do I still need to do?
  • "Continuous supply" rules, "cash accounting", etc etc etc

Terribly dull, but with more technical and commercial implications than first meets the eye!

dahowlett's picture

Nobody cares...

dahowlett | | Permalink

@bryan - all that techie willy waving counts for nothing in the minds of users. They just want to get things done. Ergo - makes no difference how/what/where...as long as it works. Tech geek types will alweays argue about these things but in the end they're a waste of tome/money. Provide a solution....move on....or not.

No argument here

bryanrichter | | Permalink

@Dennis, I agree. The "willy waving" as you describe it was only to explain why I don't think this is a SaaS vs on-premise issue. When I talk to customers about the impact of a VAT change, the things they are concerned about are all the things that Challisc mentions in his last post. They shouldn't be worrying about whether the software will support it.

As a vendor, it's our responsibility to make sure it stays that way. We can't control what the Chancellor does, but we can make sure that the software is not an inhibitor to the user doing what he tells them. Any vendor who forgets that does so at their peril.

carnmores's picture

Denis

carnmores | | Permalink

Duane would probably like to, his company is very user friendly and have been helful to me

you dont just say 'it works' and leave it at that - sometimes a more detailed explanation is worthwhile

if it is date sensitive,  and i have reservations about that, it will be interesting to see if it reverts to a new default code or simply changes the existing one - that i would say is a fair question to ask

 

It either does the job or not ....

JC | | Permalink

@dahowlett is quite right provided the software works who cares how it does. Why do you need to know in detail how a car engine works as long as it gets you from A to B without a problem?

Mind you there is endless scope for going nowhere by raising 'what if' scenarios; but all it boils down to in the end is whether it works or not. If it doesn't then adopt another provider - very simple

This 'first past the post' attitude on changes is really nothing more that a different take on advertising and keeping a high profile. This used to be particulary appealing to the big 5 at Budget time etc. to see who can get their 'opinion' in the news before anyone else

As with a number software products it is generally not necessarily the quality of the software but rather that of the advertising & keeping a presence constantly in front of the media. So really when adopting a provider the user is probably basing some of their judgement on the ability of the providers marketing department - hardly a good way to judge software!

It is just a pity that all software does not have to be subject to a 3rd party code/peer reivew behind the scenes, because one suspects if this were the case some real horror stories would emerge. Unfortunately this is simply not practical (IP reasons etc) and only manifests itself in Open Source with the collaborative approach

The way of the world is that marketing sells software and not technical ability - so addressing the in's/out's of sofware design, programming etc is a complete waste of time

 

david_terrar's picture

Not a Cloud issue

david_terrar | | Permalink

I'm with @JC and @dahowlett.  Either the software has been designed to handle VAT properly with multiple rates, and the possibility of rate changes taking effect at a certain date... or it doesn't.  It's a software thing, and the particular technology implementation doesn't matter.  The Cloud/SaaS vendors are better positioned when it comes to communicating with their customers, warning thm of what to do, and providing good online help, but that's part of their general advantage anyway.  

David Terrar

www.d2c.org.uk and www.twinfield.co.uk

challisc's picture

It's a cloud and on-premise issue – and opportunity

challisc | | Permalink

Thanks @carnmores  for confirming the user viewpoint. Pity that vendors (and their representatives) do not appear to be listening.

Whilst most but not all the issues I've raised affect on-premise systems as much as cloud, this does not detract from the point that each and every cloud vendor needs to act to check all angles are adequately covered. Cloud (and on-premise) vendors' public statements for the last VAT change suggest that wasn’t the case for them all.

In fact it's an excellent opportunity for cloud vendors to out-perform the on-premise vendors on the quality of what is offered and how it will be deployed - saving users the time and hassle the VAT change will otherwise involve. Marketing can be backed up by fact.

In any case users do want (and need) to know the what who and when, in more detail than normal. This is  because VAT-compliance is a core area, the track record of software authors is not always good (as mentioned above), and the cost, PI and customer/client-service consequences are potentially severe.

This is not just idle “what ifs”. I am just about to cut a cloud supplier (probably in public) because of their inability to bill and credit correctly, as it’s wasting so much of my time trying to resolve it. I dread to think how they are going to cope in January. Will they need to increase their staff when the complaints come flooding in? The extra costs would hurt them, plus the revenue lost as customers leave as a result! There’s six months for everyone to prepare for the VAT change, at relatively low cost, and then no excuses.

Or should on-premise vendors be given the chance to regain the upper hand?

SimonH's picture

As long as the user is in control

SimonH | | Permalink

If a system (cloud or local) allows users to change the VAT rate, and choose when they start using it, what's the problem? Users just have to think about when their cut-off is going to be i.e. when the December 2010 period ends for Sales and Purchase (for many people this will be after the change date), and change the Standard Rate to 20%. The only issue I can see if if the VAT code is hard-coded and/or date sensitive, and either the user doesn't get/install an upgrade or a cloud vendor changes the rate when some users aren't ready.  Company A comes in after Christmas, finishes some December invoicing, switches to the new rate and starts January.  Then they do the same for purchases.

Richard Messik's picture

VAT Rate change

Richard Messik | | Permalink

 Reading through he various comments on this post, I am not sure I really follow what the issues raised are about. The question of handling VAT changes is not restricted to SAAS systems or on premise ones. It is a question of how the application itself has been designed and the internal processes of the businesses using it.

If the system allows for multi rates it is a simple matter to set up a new rate - 20% - and ensure that internal processes are in place to apply the correct rate.

SimonH's picture

Exactly...

SimonH | | Permalink

...although I think the point made earlier about Standard Rate being changed to 20% rather than a 'new' rate was important.

david_terrar's picture

Still don't think it's a Cloud issue

david_terrar | | Permalink

I think @Richard_Messik has it right.  It's an issue for how the software is designed and not a Cloud or on premise issue.

@challisc - you say "Whilst most but not all the issues I've raised affect on-premise systems as much as cloud".  Which of the issues don't affect on-premise?  Also, I'm also not sure what you meant by vendors and their representative not listening to @carnmores... please explain?

Some aditional points:

  • Every vendor needs to explain to their customers how their system handles this, and the better they do tells you something about their attitude to support
  • The Cloud vendors have some advantage over on-premise  in that they have a permanent communictaion link with their cutomers and they should capitalize on that
  • If a system forces you to change a "standard" rate rather than set up a new 20% rate, I would have thought that would cause you problems with the timing of transactions.  The systems I've worked with would allow setting up of a new rate, so you can handle it in your processes easily in the way Richard suggested. . 

David Terrar

www.d2c.org.uk and www.twinfield.co.uk

cverrier's picture

Violently agreeing?

cverrier | | Permalink

I would 100% agree that cloud/SaaS providers are no more likely to get this right than on-premise suppliers (in a purely technical sense of how to write software).  Bad design is bad design - however it is delivered.

The point is that cloud providers - by the nature of the way they work - are in a much better position to deliver the changes to customers in a painless way.  My previous example of the way FreeAgent delivered the 15% rate change was an illustration of this, as I didn't have to worry about downloading or receiving an update pack and then fnding the time to back-up my system and then install the update pack on my live system.

With my cloud application - It all just happened, when I needed it to happen, while I was at home with a nice glass of wine.  I'm a small business with no IT department, and I simply don't want to spend time on that stuff that can be better spent doing chargeable work or playing with my kids.

 

another point...

 

Cloud providers do also have one logistical advantage in that they do not have to carry out vast amounts of environment testing. Because cloud software only runs on their own, tightly controlled, equipment, they only have to test the new software ON THAT EQUIPMENT rather than umpteen different combinations of Windows with this that and the other service packs, etc.

What that means is that cloud providers can react faster than on-premise providers, for whom QA testing is a never-ending hassle, and which prevents them from releasing updates more that a few times a year at most.

david_terrar's picture

Yep, violent agreement

david_terrar | | Permalink

@ceverier - completely agree with all you've said, and good to hear your positive experience with Cloud providers.

The point you raise on the testing is really important.  As an example, when I was at CODA we had to test every new release against 26 different hardware/operating system/database combinations, and even then we weren't covering everything.  It can be a real nightmare. For SaaS develipers it's the combination of being in total control of ONE development and testing environment, plus doing releases in small, manageable chunks on a regular basis that mean you get much fewer bugs compared to the traditional approach. 

David Terrar

www.d2c.org.uk and www.twnfield.co.uk  

carnmores's picture

this is a very good point

carnmores | | Permalink

and should be used more in the selling of cloud under the stability / risk tests

dahowlett's picture

@carnmores - FWIW

dahowlett | | Permalink

I'm currently in the middle of a study into the factors that play into making cloud decisions beyond the usual opex/capx arguments and discovering not just anticipated but expected benefits. There are a lot of interesting surprises in store.I'm also looking at how risk is assessed, the dimensions across which it touches and how those are moderated as part of the decision making process.

The object is to discover from the end users' perspective exactly what's driving them (beyond the inevitable hype effect) and how that's panning out for those same user orgs. There's much to be learned and hopefully will serve to help clear the air in a lot of these sterile arguments tat end up going full circle.

challisc's picture

Give & Take

challisc | | Permalink

To answer @david_terrar’s questions:

(1)  “Which of the issues don't affect on-premise?”

Sorry if I wasn’t clear, but as I mentioned in the original post, specifically relating to SaaS cloud services:
“Understanding clearly who is going to do what when will be critical. Users remain responsible for VAT compliance, so:
• What will users be able to control themselves?
• What will need to be done by the vendor, both in preparation and during the transition?. “

For example, who is going to change the rate? Tell me this sort of thing won’t happen between users and cloud vendors: “I thought you were doing it” “No you were supposed to do it” “I thought you were” etc. On-premise users are more likely to know it’s down to them – unless it proved otherwise last time.

As users, what else needs to be clarified with your specific software? I’m not just talking about back-office book-keeping systems, but anything that involves VAT – from quotation systems to employee expense claims and full-blown ERP – especially if they are in the cloud.

I also mentioned in relation to any SaaS webshops you may be using, especially if they are US-based will you “have to change all the prices because they are VAT inclusive”? And what about VAT in any cloud APIs?

There’s probably a few more – which would come to light after a careful look at all the relevant software in a business and what it’s doing.

(2) As to not listening to @carnmores, you said” I'm with @JC and @dahowlett.” who were both at odds with what @carnmores had said. He said he wants to know the detail, as do many other users who are responsible for VAT compliance. Many of us don’t just want to take the vendor’s word that things have been covered.

I’m pleased you subsequently said “Every vendor needs to explain to their customers how their system handles this, and the better they do tells you something about their attitude to support” Spot on.

P.S. Talking about the real world, @dahowlett asked: “..do you think peeps are that daft that when they bring those transactions into their own systems they wouldn't see that happening and query?” Yes in many cases! Not because they are daft, but because they don’t have the experience nor an accountant’s mindset.

david_terrar's picture

Thanks for answering

david_terrar | | Permalink

@challisc - Thanks for answering. 

I still don't see the issues you've raised as specifically Cloud/technology based, but more of a vendor choice.  These are software issues, whatever way the particular  product is delivered.   Some vendors might make those sort of rate changes on behalf of their customers with an update, others will do it  by providing a flexible rate table, ability to maintain and so expect the customer to do it themselves.  In that first circumstance, the Cloud providers would be able to do a faster, better job.  I'm more used to vendors who do the latter. 

On @carnmores and the detail - completely agree that a vendor needs to provide their customer with proper instructions.  I worry that if we put too much detail here about how our particular product handles it, that will look like just another sales pitch.  However, we'll be guided by your moderation.

David Terrar
www.d2c.org.uk and www.twinfield.co.uk

challisc's picture

Shock to the System

challisc | | Permalink

Thanks David. Everything in moderation is probably the right approach. I have no problem with links to vendors' webpages on issues like VAT and security, which are of genuiine value rather than just salesy.

Thanks also to @cverrier and others for some very useful points. Though I’d say that if the software has been properly designed or already upgraded, no new upgrades would be needed anyway.

With the exception of the points I’ve just answered to @david_terrar, this simply isn’t about “cloud vs on-premise” – which seems so deeply rooted in peoples’ psyche. I could have written a similar piece in the “On-premise accounting” group if there had been one. Let's get beyond that to understand the benefits of cloud and actively tackle the risks with good ideas, shall we?

SO WHAT'S THIS VAT TOPIC ABOUT?

It's about cloud vendors (and on-premise vendors) making sure they’ve got this topic covered, and potentially using that to gain a marketing advantage.

Reading through the comments I'm not sure the issues are fully understood, despite my explanations – or maybe because of them.

On the commercial side, have people had the privilege of two VAT inspectors descending to find what mistakes and penalties they can draw out of you to help meet their recovery targets? And the satisfaction of seeing them leave empty-handed? That comes from preparation. (Having passed audit twice by the then Chairman of the Auditing Practices Committee, whilst I was in industry, I tend to like to keep a clean sheet.)

On the technical side, two opposing views are being expressed about either using a new rate code, or changing a rate code. Actually it depends on the software, such as whether there are sales orders and the like with VAT codes pre-populated into the order lines.

I highlighted the “code vs rate“ issue in my blog within a couple of hours of the November 2008 budget, as I sat down to consider the changes to R&D tax credits, the EIS scheme and other matters relating to high-tech businesses.

My own preference (though as rare as hen's teeth) is to keep the same VAT code, as @cverrier suggested with date-related rates which can be pre-defined - unless there is a very good reason with specific software to add a new rate code. Either way VAT reports then need to clearly show transactions grouped and sub-totalled by rate so that VAT:net ratios can be checked. Where such rate flexibility has to be added, programmes such as invoicing, credit notes and supplier invoice entry need to be amended to take advantage.

(Sorry if I’m sending you to sleep on this. I’m only just staying awake myself! But it is important, especially for those of us with clients and PI policies,)

cverrier's picture

actually

cverrier | | Permalink

I don't think my FreeAgent software even HAS a place to let me manually change the rate - I leave it all to them!  

No confusion there about who's doing the work!

Of course, FreeAgent is designed for small freelancers, so maybe there's an assumption that I don't have very complex VAT (beyond the Flat Rate Scheme stuff, which appears a bit more involved when a rate change happens).

I'm curious - Does Xero or Kashflow allow users to muck about with VAT rates?

 

Interesting to see cloud suppliers taking advantage

mhakhtar | | Permalink

Multi currency software houses use a similar sytem to change the rates of currencies linked to dates.

Currency rates are changed more frequently than the VAT rates without causing undue problems to end users.

Xero accounting uses a multi currency option far more sophisticated than Kashflow.

 

garyturner's picture

VAT rate changes in Xero

garyturner | | Permalink

We allow users to maintain various VAT rates for; standard VAT, Exempt, Zero rated transactions and so on.

As for the rate switch, we have yet to write up our guidance for the forthcoming switch, but this is how we handled it and what we advised our users in January this year.

 

Add comment
Log in or register to post comments
Group: Cloud Computing for Accountants discussion group
A place for accountants to share their thoughts about web-based systems