23 Jul 2015 The trouble with Vanilla
In every purchase to pay implementation I have been close to there are two things that I have heard every time. First is comment that we might as well just replace the whole ERP system. Perhaps the ERP system is worn out and no longer meets business requirements. Or maybe it was designed and built to meet finance and accounting requirements and it never took into account the needs of the rest of the business. Or maybe there’s plethora of disparate systems – a legacy of a series of mergers and acquisitions. Whatever is said, the real issue is that it is difficult to get a comprehensive purchase to pay system implemented in the real worlds because the real world is full of idiosyncrasies. It’s like saying “If that mountain wasn’t there we wouldn’t have to build this tunnel”. The ERP mountain is there – and it’s not moving.
The second thing that is invariable said at the early stage of selecting a P2P system is “Rather than looking for a solution that we can mould and adapt to our business requirements, we should select best in class and adapt our ways of working to the out-of-the-box vanilla solution”. This makes some sense and this approach can work on a small scale but for medium and large enterprises this approach can never work. And it’s because the underlying assumption that there is any such thing as a vanilla solution that is fit for purpose is flawed.
I’m not saying that the solutions out there are no good. I’m saying that it is an unrealistic expectation of these solutions to assume that, without some customization they will meet the needs of any business other than some very small one. I saw an example recently. A small business in the UK using a very highly respected accountancy tool used successfully by millions of businesses. As a very small, agile business, it had no problem following standard process in order to work with the accounting package. A fully global accounting solution, it is even able to accommodate the complexities of European VAT – until it meets the “reverse charge accounting mechanism”.
To quote HM Customs and Revenue: “Under the reverse charge procedure, the purchaser of the goods rather than the seller is liable to account for the VAT on the sale. The supplier should not charge VAT, but has to specify on the invoice that the reverse charge applies. Purchasers who have correctly declared output tax under the reverse charge procedure are entitled to input tax recovery subject to the normal rules. Output tax chargeable under the reverse charge procedure and corresponding input tax should be entered in the same return subject to normal tax point rules.”
Pretty interesting stuff I’m sure you’ll agree!
The reverse charge mechanism was put in place to prevent a sophisticated VAT fraud known as “carousel fraud” and it is an example of how complex European tax laws can be. Accounting and P2P solutions, particularly those that address a global market, need to be extremely sophisticated to understand these kinds of local anomalies. And I’m not only talking about VAT – a P2P system has to recognize the subtleties of the entire business process from purchase to pay – from accounting rules and taxation through to logistics and customs issues.
Adapting business processes to a good vanilla solution is a worthy aspiration. Preparedness to change business process is essential, but so is a preparedness to adapt the vanilla out-of-the-box solution. Sorry – there’s no getting away from it.
