Accounting Software as a Service

Software as a Service has come to a point to offer a large variety of applications. In its beginning it was all about simple functions, since vendors weren’t too sure about the future of this business (and therefore they were reluctant to make big investments in that area) but also due to the technical complexities that needed to be sorted out before one could deploy and offer an enterprise-scale application (issues like security, access rights, redundancy, disaster recovery, virtualization etc. were not solved in one night).

Today, one significant part of the SaaS business is the Accounting Software. One can find a number of vendors that offer this kind of software, starting from small, local businesses and going as high as international players such as QuickBooks and others. But, today, I would like to explore whether there can be a future dominant SaaS Accounting Software, or local solutions will maintain their market share.

The basis of thinking is that, although Accounting is surely governed by some scientifically generally accepted guidelines (such as GAAP – General Accepted Accounting Principles), each country/market has its own specific rules and legislation that drives local accounting software to always get some “flavor” of the market in which it was originally developed. Furthermore, if we are talking about countries were local legislation changes very often, then there is additional effort for the software vendor to keep their software up to date.

Here are some examples:

• In some countries there are a number of reports that must be printed on paper, in specific dates following the month-end. These reports contain a specific set of data which is “non-negotiable” (i.e imposed by local tax legislation). Also, the printed form is non-negotiable. Users (especially chief accountants) expect that the software provides such reports “out-of-the-box”. Any additional customization effort (and cost, for that matter!) on behalf of the vendor will not be tolerated. This is an obvious obstacle for the success of foreign software in such countries, in the sense that there is some significant investment on behalf of the vendor to initially construct the requirement, but also recurring costs for keeping it up to date.
• When operating in local level and if vendors target to SMB’s for their customers, perhaps multicurrency support is not an issue. But when they target to expand outside their country-of-origin geographical borders, then it becomes a must. Even if they acquire customers who do not face any multicurrency issues, the simple fact that they operate in different parts of the world automatically creates the need for – at least – the maintenance of a “currency” table and default values in all screens and reports. In addition, operating in a multicurrency environment is not just about a “currency field and exchange rate”. Historical exchange rates must be kept in analytical tables, monthly differences due to exchange rate changes must be properly analyzed and booked. Specific reporting requirements may exist, per country etc. which makes the issue much more complex. In fact, a vendor that targets another country should first get some solid consulting and insight of what this countries requirements are, when it comes to multicurrency…
• Local tax compliance and tax calculations can also be an issue. For example, EU countries all have the VAT (Value Added Tax) concept in their business transactions. But that’s just a general statement. Aren’t there any exceptions? Of course there are and your accounting software should be in a position to handle all of them. Remember, that it’s – again – an issue of compliance and customizations: additional costs or necessity for manual checks on behalf of the user will not be acceptable.
• In the same spirit (of tax compliance) you might find some very specific needs in local software, such as interfaces to external (i.e. government) systems that require the company’s feedback in a periodic scale.
• We also shouldn’t forget the issue of the so called “nice-to-have’s”: Functionality which may not be mandatory by law but is indeed expected by the average user or the chief accountant. Here is a small list of some:

• Pre-loaded Chart of Accounts. In cases such as Greece, where some “depth” of the CoA is defined by local legislation (and the rest of the analysis is left to the hands of each specific business), some accountants would expect that that portion of the CoA is pre-loaded into the system. One can easily understand that supporting this kind of parameterization, per country, can be a real pain.
• Pre-fabricated “standard” reports (additional to the local legislation mandatory reports). There can be a number of standardized reports through which a country’s companies and accountants are “used to” do business with. And they are most probably not prepared to forget them, when the new accounting system is installed. Examples can be the P&L and Balance Sheet report, which – although standard in essence – can be different in form from one country to another.
• In the area of Voucher handling, not all countries are as susceptible to a small number of “do-it-all” vouchers (such as the all-time classic trio: invoices, credit notes and payment orders). Different voucher types will be required to handle different business cases, according to local legislation and the SaaS software should be in a position to handle all of them. The keyword here is “all”, otherwise you will receive the accountant’s read flag about your system not being “local-ready”!

• User support is yet another story: You can surely expect to face some issues (not necessarily software “bugs”) with the new accounting software. And you will definitely need to speak to your vendor Customer Support dept. and perhaps get some consulting like “how do I use your software in order to meet X, Y or Z tax requirement?” You can imagine the problems that a foreign vendor will have until they come to a level of understanding, similar to that of your chief accountant (if ever!).
• Last, but not least, is the issue of local practices. Supposing that we have surpassed all the “localization” issues, we have to talk about the “functionality” issues. From my involvement in building accounting applications for many years and in my effort to make them work in other parts of the world, I realized that different markets require different set of functionality with varying “weights”, each. For example, in the US market where cash transactions are very rare, printing of cheques is a must for all accounting software. The same applies for UK, too. In Greece, on the other hand, printing cheques is a nice to have for a large number of SMB’s. In the contrary, handling of post-dated cheques (not necessarily printing them), which is a purely Greek concept, is a must for any – big or small – accounting dept. I surely do not expect any non-Greek software to cover this functionality!

Other examples do exist and thus I make the point that local practices play a significant role on the accounting software’s functional building blocks. Therefore, the selection of foreign accounting software is not an easy decision, just because it has a large customer base and it has proven its value over time. Maybe, this is the case with legislation-agnostic software (such as CRM, Collections, mobility enablement etc.), but when it comes to Accounting, you can’t escape taking a good look at your local market offerings! In that sense, I believe that a future dominant Accounting Software vendor is not likely to emerge because the accounting function has and will always have a strong essence of locality.