Switching to a new ERP system in Russia – the correct cut-off date

There are rumors that in Russia it is obligatory to start with new system at the beginning of the new tax period, which is equal to the calendar year in Russia. Thus, many companies in Russia aim to have the go-live date as the 1^st of January. I’m constantly receiving questions “What is the correct time for switching to new system in Russia, and what should be the cut-off date? Can a new system go-live in the middle of accounting period? What are the consequences of such action?”

I feel a need to group answers in the following article.

First of all, there is no any legal limitation in Russia for the cut-off date when you transfer your operations from one system to another system. There just should be some system that allows you to keep your bookkeeping and tax registers in order – just be sure to provide tax reports in time. Thus, it is not obligatory to have the go-live date as a beginning of accounting period. However, there are several practical reasons for doing so in Russia.

Accounting period and data transfer

The reporting period of some taxes in Russia is one year (equals to calendar year). This is valid for the most common profit tax, property tax, social taxes. In order to provide correct tax statements, as well as internal management reports, users will need the data for the whole accounting period. In some cases, they will need this data on a transaction level.

When switching to new system, one of the biggest issues is the data transfer. Generally, there are two options to deal with the transfer of data from old system to new system:

• Transfer just the balancing figures at the cut-off date on a necessary detail level (e.g., open invoices of the customers / suppliers, ending balance of items in stock on item level, etc.). If the switch to new system takes place in the middle of the accounting period, users will have to switch between two systems until the accounting period ends. This will require keeping the old system for some time and additional inconveniency and time consumption for operating with two systems.

• Transfer information from old system to new system on a transaction, or even a document level. This will allow users to dedicate themselves to one new system, but such transfer of data from old system to new system on transaction (document) level might become times more expensive then transfer of balancing figures.

In order to transfer information of a correct transaction level, in many cases it is not enough to transfer just transactions from financial ledger. Ideally, all the ledgers should be transferred (including customers/vendors, items, VAT, Fixed Assets, etc.). To achieve this, non-posted documents should be generated in new system and then posting of those takes place. This enables the new system to create the needed transactions in all needed ledgers by its own internal mechanisms.

It is exactly where the danger is. Such transfer of documents should result in new system exactly in the same transactions as in the old system, and this can’t be guaranteed. First of all, different systems may by nature process the same transactions differently, and this can cost a lot to synchronize the posting engines of two systems to get the same posting result in the end. But even if the posting engines are similar, there might still be issues. Imagine that in the old system, in the period that is already closed, there is a mistake in the currency exchange rate. This error needs to be also transferred on a document level into new system in order to have both systems identical. By default, the new system will use the correct exchange rate and will post the documents differently. When dealing with automated transfer of big volumes of data, there would be just different results in the ending balances in both systems. This might take lot of efforts to verify what document exactly caused the difference.

It is usually more convenient for the users to analyze data within the same accounting / tax period on a detailed level. Thus, whatever the data transfer method is selected, going live in the middle of the accounting period can potentially be more expensive for the company and inconvenient and ineffective for the users.

Accounting policy

Changing accounting system might also require a change in the accounting policy. E.g., a new method of cost of goods sold calculation could be applied in new system. According to Russian accounting legislation requirements, accounting policy can be changed once per year only, from the beginning of the accounting period – that is, from 1^st of January.

In some rare cases accounting policy can be changed in the middle of the year, but this would require application of these new principles from the beginning on current accounting period and consequent recalculation of transactions made during the year so far. This task can be very challenging, if even possible. It can also lead to unnecessary tax fines if previously reported taxes turn to be lower. Therefore it is yet another argument for going live with a new system starting from 1^st of January.

Reporting structure

In many cases the switch to new system takes place because of the new owner of the company or due to some significant changes and investments. If so, it will most likely lead to new reporting requirements. This in turn will affect the structure of the General Ledger and details level of analytical dimensions of the system.

E.g., there might be a requirement to present on a monthly basis some costs in the Income Statement on a more detailed level breakdown then earlier. Having it previously half year as more generalized transactions, it requires a lot more efforts and manual work to prepare the required reports on a necessary detail level for the whole period.

Availability of resources

Reliable IT partner that helps in implementation of new system is a key element in successful project. But successful go-live is also impossible without commitment of internal employees. They should dedicate their time and efforts to learn new system, test it and ensure that it works properly and efficiently. This efforts are usually additional to their current normal workload, thus it becomes even more challenging task – to keep the business up and running and simultaneously support the transition from old system to a new one.

The specifics of Russia here is a long New Year and Christmas holidays that usually take the whole first week of January, or even longer, depending on the weekends. This time is a perfect period for IT partners to operate with go-live of a new system and manage the data transfers, since in best case company is not working with its old database. Upon agreement, internal employees also might be involved into the testing process without damage to daily operations.

Thus, it is also more convenient to go-live in the 1^st of January with new system.

Summary

Regardless the fact that in Russia there is no legal limitation for going live with new systems any time of the accounting period, there are several practical reasons to do so – keeping correct accounting policy, reporting requirements, data transfers. Accounting year in Russia equals to calendar year, therefore it is plausible to start new system at 1^st of January.