Having a fully integrated job costing and accounting system, that works perfectly in one country, should make it relatively straightforward to employ it in other countries as well. After all most modern operating systems are able to provide a more or less seamless international and multilingual functionality on the touch of a few buttons. In particular for a multinational company having easy access to all of their systems across borders is an important aspect of management.
The mere translation of the project management interface is indeed quite an easy part of the localisation as most languages have words for “project” or “sales invoice” etc. There are however two main issues that will arise, one due to the integration of accounting and one due to the multilingual interoperability of the system:
This first part of the article will look at the Accounting/Bookkeeping issues facing multinational organisations and come up with suggestions of how to best address them when localising a software. The multilingual accessibility issues will be addressed in a Part II soon to be published on this forum:
Despite the fact that all modern accounting rules everywhere are based on the double entry bookkeeping procedures developed several hundred years ago in Northern Italy by Cotrugli and Paciolo there are slight differences in their application in different countries. Taking aside company taxation and sales tax rules – even some of the more basic bookkeeping procedures and regulations differ from country to country. Following are just some examples of those subtle differences:
– Anglo-American bookkeeping gives the user relative flexibility with regard to how they code their accounts or how they number their transactions
– Spain has fixed GL codes that must be used as the basis of all systems in those countries
– Germany where there used to be a prescribed coding structure – like in Spain – has relaxed this rule, however the historical structure is still used as a semi standard as the main accounting software used by the association of tax advisors is built around this structure
– In Italy there is a rule that the sequence of transaction numbers has to be validated against the date of those transactions
Although it is possible from a programming point of view to adapt the software to accommodate all those different regulations, it makes a program grow immensely in code and complexity. This is even more the case where in different countries contradicting rules need to be applied. So what is the best way for a software to incorporate the requirements of international functionality?
Two approaches come to mind:
One possible way would be to not apply any changes for a particular country in the core coding of the software, but have optional modules for different localisations.
The core of the client software would contain only the basics adhered to by every national accounting system, such as the double entry principle, whilst the add-on modules would apply additional validations and rules to the data processing. Changes to any of the modules could easily be tracked, testing would be straightforward as only one module would be affected and the whole setup of both the client as well as the data base would remain clear and slim.
Having add-on modules would however mean that the software can no longer be called “multinational”, but would now be just a framework of many localised independent software systems. A client installed with one localisation would not be able to access a data base used with a different localisation. In particular in bigger multinational companies, where a group auditing is necessary, this would be a big disadvantage.
Another solution would be to have a switch in the data base to either apply – say – the Swiss or the Polish rules. That switch in the data base would trigger a second switch in the client software that logs into it to use the right local settings. In a simplified way this may be compared to a word processor document where the text is specified as being a particular language and the word processing software then applies the spell check for that language.
A downside of this solution would be that all the settings and switches in the data base would also mean a growth of the client software to pick up all of these and that every increase of software coding brings with it a growth of the possibility of bugs or other faults.
The big advantage would be that this way allowed for the client software to be used against any of the accounts data files used in different countries. Multinational group headquarters would only need to use their one software installation to log into any of the overseas accounts and project management data files. Despite the risks due to it’s increased complexity and the impact this solution would have on any testing department of a software house the added flexibility and interoperability of this way seems to make it the most preferable solution for equipping an integrated project management system with a truly international accounting functionality.
Volker Bendel