This article was published at the September/October edition of «Accounting Report» by International Center for Accounting Reform (ICAR)
Introduction
Today's changing environment puts constant pressure on all enterprises starting from a small family-run business to international giant corporations. The need for cost reductions and customer service improvements goes side by side with the need for more accurate, full and timely management information. Management information systems (MIS) are designed to help to achieve these goals. However, the process of system implementation brings a lot of problems including technological, psychological, change management, legal and other issues. One of the key success factors is a clear understanding is required of both the problems and benefits of system implementation.
Also MIS implementation projects in Russia have special requirements such as the need for dual standard and dual currency accounting. Our experience shows that there are several reasons for Russian companies to use both Russian accounting principles (RAP) and IAS:
- RAP is traditionally designed mainly for reporting to tax and other authorities, and provides little opportunity to prepare relevant and adequate management reports. The company may wish to use IAS for the purposes of improving the quality of management reporting.
- The requirement to report to international headquarters.
- The intention to obtain investment funding. A properly implemented MIS will not only solve an automation problem by eliminating the need for multiple entry of the same data and speeding up business processes, but it can also make all business processes more transparent and easier to monitor. This facilitates the decision making process and, at the end of the day, helps to attract investors.
Technical solutions for dual accounting
Prospective users should be aware that no software package can automatically make postings according to IAS, GAAP or any other accounting standard. Systems only facilitate this. Usually they include sets of interrelated tables and parameters which need to be filled in and configured according to the enterprise specific requirements. Others may contain pre-configured sample charts of accounts. The final customisation still remains the task of the implementation team in both cases.
Before going into details regarding the specific issues of dual accounting implementation, it is worth giving an overview of the possible technical solutions of dual standard accounting. However, the actual solution will depend on a number of factors including the level of details required, budget constraints, system capabilities, project deadlines, and availability of staff with relevant skills.
Overview of possible solutions
The main options are as follows:
- In rather simple systems one database can be used for both RAP and IAS accounting. In this case only the RAP chart of accounts actually exists in the system. IAS accounts are recorded as analysis codes or implemented as the extension of RAP account numbers. Each transaction is posted into the system to RAP accounts but in several currencies. Ideally, there should be the possibility to register transactions in roubles, a second reporting currency (which is often US dollars) and the actual transaction currency. Later IAS accounting information could be prepared using sophisticated report generators.
- For medium complexity systems such as, for example, SunSystems, transactions are originally entered into one database with RAP chart of accounts only. At the period end the transformation procedure is performed during which transactions amounts are automatically recalculated using appropriate currency exchange rates and transferred to IAS database. RAP-specific transactions which should not be reflected in IAS books are not included. IAS-specific transactions will be later entered to IAS database as adjustments.
- Many systems support more than one database which can be used to maintain accounts according to different accounting standards and in different currencies. The scale of systems which maintain this scheme varies significantly from 1C to SAP R/3. Specific technical solution and provided functionality may be quite different but the main underlying principle – simultaneous posting to both ledgers – remains as the distinguishing feature of this approach. The In this case for the purposes of dual accounting at least two charts of accounts – RAP and IAS – should be maintained in two parallel databases. The Russian chart of accounts is usually set up as the main one with each account mapped to a corresponding account in IAS chart of accounts. When a transaction is entered into one ledger, it is simultaneously posted to the second one.
Advantages and disadvantages
Each option described above has its own advantages and drawbacks.
The first solution, though looks cheap at first, may prove to be inadequate and hard to implement in real life. Based on a simple architecture, it may require very sophisticated reports which will be difficult to generate and even more difficult to support in the future. In addition, special attention will need to be paid to IAS adjustments.
The second option where the transformation at the period end is used is more viable. One of the main drawbacks is that IAS information is only available at the period end, and adjustments may still need to be made after the transformation. On the other hand, the transformation process (once configured properly) can be run completely or partly automatically. One responsible person with relevant IAS knowledge can be assigned responsibility for performing the transformation and making the necessary adjustments. Therefore, no IAS skills will be required from ordinary accounting clerks who enter transactions daily.
The situation changes significantly if the third option is chosen. This solution will provide much more detailed IAS information which will be available at any time. However, using this approach will probably mean a more complicated structure of the charts of accounts and pre-set standard accounting transactions. In some cases detailed knowledge of RAP-IAS differences maybe required by accounting clerks responsible for entering transactions. This approach also does not solve the problem of double entry for those transactions in IAS which can not be mapped directly to RAP, for example, accounting for fixed assets.
The final decision as for which one to choose depends on various factors including software and implementation costs, specific business requirements, etc. However, proper consideration should be given to the advantages and disadvantages of each approach before one of them is selected.
Implementation issues related to RAP – IAS differences
The accounting reforms made in Russia to move Russian accounting standards closer to IAS should finally eliminate most of the issues which arise during dual accounting implementations. However, today the problem still exists, and the main differences between RAP and IAS to be considered during implementation are as follows. These differences are especially important when the third approach is used.
- First of all difficulties might arise due to the different level of details in the RAP and IAS charts of accounts. Several RAP accounts might be necessary to map to a single IAS account or vice versa. Not all systems are capable of maintaining relations other than «one-to-one». In this case it might be necessary to split accounts into several sub-accounts even for quite straightforward transactions which are the same in both RAP and IAS.
Another issue relates to the different timing and nature of period end procedures. Along with the fact that different fiscal years and accounting periods might be defined for RAP and IAS, the nature of period closing procedures differs. In this case period end procedures will have to be performed separately in two databases. - Accounting for fixed assets also represents a problem. Different depreciation methods and rates may be used in RAP and IAS. This can lead to the situation where an asset is still being depreciated in one ledger after its disposal in another, and so corresponding accounts in two databases can not be mapped directly. The solution will be to account for fixed assets separately in each of them. For this purpose either off-balance accounts should be used or individual postings to both ledgers.
- The same is applicable to accounting for low value items: they may be fully expensed in IAS when acquired and depreciated in RAP when put into operation.
- Entering transactions of the same nature separately into two databases does not represent a technical problem in itself. However, our experience shows that people usually react negatively to the necessity of doing «double» work. They also tend to forget to do it or make mistakes if the task is not considered crucial for their everyday work: IAS postings are not needed for reporting to a Russian tax inspector.
- A further problem relates to the different timings when a liability is recognised in RAP and IAS. For example, when an invoice for a prepayment is issued it is also reflected in the books in IAS. However, a proforma-invoice in RAP is not a document by nature and no accounts are affected when it is generated. A debt is recognised only when a factura-invoice is issued. A similar problem exists with the cash accounts: they are updated in RAP on the basis of the bank statement, in IAS – on the basis of payment order received or issued.
- Other issues are related to inventory valuation. Inventory valuation methods can be different in the two books. Also the system should ideally be able to support inventory costs in two functional currencies for easy and effective reporting.
- Additional problems might arise when configuring Accounts Payable and Accounts Receivable for posting invoices in two currencies. Some manual adjustments may be required when the invoice is being closed because when the payment is allocated with the corresponding invoice thus closing it in one currency it should also be closed in the second book.
The list of differences between RAP and IAS which affect the implementation process continues. It is important to recognise this area as potentially risky, it requires careful attention from the implementation consultants and also significant involvement of the Chief Accountant and other relevant specialists of the enterprise.
General implementation problems and role of consultants
Problems which may arise during implementation, after system goes live include but are not limited to those described above. All MIS implementation projects have common issues and we believe it is worth reviewing these general issues briefly.
Project management
Firstly, although system implementation seems a rather technical task, it is extremely dangerous to underestimate the importance of the human elements. The impact of change, people's natural resistance to change and the fact that different groups may have different interests – all this should be identified and measured as early as possible to ensure that an appropriate strategy is worked out to overcome any situations which can threaten the success of the project.
The client«s staff availability is always a problem for implementation projects. However high the consultants» skills are, the involvement of the key personnel from the client side is always required. This is one of the tasks of the project manager to ensure that the project is not being postponed repeatedly because of month ends, year ends, vacations, sick leaves and other real and imaginary obstacles.
In general, project organisation and management is a difficult task which requires experience in different areas, not only technical ones but also in people management. Decision on which strategy to apply – push or pull – is a hard one to make since external consultants often find themselves in the position when they have to push client's personnel although their status in the company does not allow them to do it.
Business requirements definition
Another important task is the business requirements definition. Quite often the users' expectations are too high, they would like to make every step automatic and regulated in the new system. Following this path the project team risks ending up with too complicated a system which is difficult to configure, operate and maintain. Therefore, a compromise is always necessary. This is impossible without deep understanding of the business processes of the enterprise. Frequently business process improvement is also needed prior to system implementation.
Change and version control
Later in the project change control procedures should be in place to ensure that each change to the system design requested from users is evaluated and costed. Often such requests are driven by the changes in the statutory requirements or RAP and IAS alterations. The adjustments which need to be made in the system may be numerous even if a slight change in the standards was made, however, modern MIS are usually flexible enough to reflect changes in the environment.
The same applies to installation of the new system releases. Usually this is done to add new system functionality and to amend any errors in the older versions. However, with each upgrade we run the risk of the needing to configure and test some of the system parameters again.
User training
Another area crucial for the success of the whole project is user training. An appropriate strategy should be developed taking into consideration the scope and amount of work and costs involved. The project team has to decide whether to organise the total training for all employees or just for the key users who will then share the new knowledge throughout the company.
Data conversion
Data conversion is a task which is quite important for the success of the whole project. Usually by the time when the new system is implemented the enterprise has already a long history of business transactions which should be uploaded into the new databases. This task requires a trade-off between the desire to make the start as smooth as possible with all possible data available in the new system and the minimisation of additional costs for the data entry. Hence it is important to identify the real requirements (what data, what level of details, what period if any or opening balances) for initial data.
Another issue to be addressed is data adequacy and data verification, especially if no proper integrated system was used before. For example, different departments could operate using different software packages, some of them being simple standard ones, others might have self-developed programs. This could lead to increased paper-work and the necessity to re-enter the same data several times into different systems. Also additional data gathering might be required as more new system parameters and master files are supported by the new system (e.g. additional levels of customers and vendors classification, multiple ship-to addresses, cost centers, etc.).
When the requirements and scope of work are identified different approaches for data input should be considered. In general the following options exist:
- manual entry into the new system; the main disadvantages are: the higher risk of typing errors and the long time required; this option must be used when the volumes of data are not significant and it would be cheaper to upload them manually rather than to configure systems for automatic data load;
- using export/import functionality or special tools available in both systems (for the old one export is required, and for the new one – import); the main problems here are with the availability of these functions in the systems and the compatibility of formats;
- development of custom programs which would either load the data directly to database files (this is extremely risky and hardly used in practice), or through emulating input from the keyboard.
Whichever option is chosen the joint effort will be required for the whole project team to make it work.
System go live and post-implementation support
After the system is configured and tested and after all users are properly trained the last two tasks remain – to organise the new system go live and to ensure that relevant system support capabilities are available after the consultants leave the company.
There are two main options for the system to go live: parallel run with the old system or full start up of the new one when all bridges are burnt by shutting down the old system. In the first case the risks of the new system failure for the whole enterprise are lower, however, it will make more difficult to start really using new system. Also it puts additional pressure on end-users who will have to duplicate their work in both systems.
The second option might be dangerous if the new system fails to operate properly. If the company then needs to revert to the old one there will be little chance in the future to start the new system again. General frustration and disappointment will affect the project much more than any technical problems. In order to avoid this thorough system testing is required prior to go live.
And the last but not the least task is to provide system support after the consultants go away. Our experience shows that a special person within the company should take responsibility for system support and further development. This can either be an additionally hired specialist but ideally this person should be involved from the earliest stages of the project. This seems to be the optimum approach because the client does not need to depend solely on consultants in the future, however sad for the consultants it might be.