Designing Russian CoA for International roll-outs: how to make corporate reporting easier

One of the first issues you will face when making a roll-out of your solution is how the local Chart of Accounts (CoA) should look like. In some countries the structure and numbering is flexible, in other countries it is statutory rigid. For Russia, there is so-called "recommended" CoA structure with "recommended" numbering. I wrote about the CoA some time earlier here:

https://community.dynamics.com/nav/b/russianerpexperience/archive/2016/04/02/designing-chart-of-accounts-and-analytical-structure-russian-accounting-habits

So, the main idea is that you most likely will keep the recommended numbering of Russian accounts and maintain traditional structure. However, there is also your corporate "global" CoA, with its own structure and own numbering. This will be very good if there will be some kind of mapping between those accounts, available for the financial controllers, right in the system, won't it? This will require that you will plan and design Russian CoA the way it will be as closer as possible to the corporate CoA, within Russian legally allowed boundaries. This is usually a very challenging task, where trusted local partner, such as Awara IT Solutions, can assist.

Here are the options you can consider for Microsoft Dynamics NAV case:

• Include the corporate number of account into the Russian account code after number of Russian account. E.g., if your corporate account number for booking revenue is 3745640, and you had created Russian subaccount for booking the same type of revenue as 90.01.01, you can have the final Russian account number as 90.01.01-3745640 (remember standard NAV has Code 20 type of the No. field, thus no more than 20 signs you can plan). This is a very easy solution to match Russian accounts and corporate accounts already on the CoA page. Regardless the fact that this code will be available in G/L Entry records (and this can allow you to play with corporate accounts in Excel easily), you will not be able to sort them easily by corporate accounts number in NAV CoA page. Also, you will need to write the name of the account in both languages using e.g. slash "/" in the same Name field for convenience purposes.
• Another option is to utilize standard No.2 field (which has the same Code 20 limitation in standard non-modified version). Thus you can put Russian number 90.01.01 to No. field and corporate 3745640 number to No. 2 field. However, there is still no Name2 field, and you will need to write the name of the account in both languages using e.g. slash "/" in the same Name field for convenience purposes, or make a small customization and add Name2 field to the G/L Account table for filling it with corporate account name. This would allow you to filter and sort the accounts by corporate accounts much easier, but you will not see the No.2 field in the G/L Ledger entries unless again you will not do a small customization (e.g., add those fields to G/L Entry table as flowfields or customize posting routine to fill them up with corporate values from No.2 filed in the account card).

Both previous options are good to be a fast solution without pretty much customizations. However they cover only a situation where one-to-one accounts mapping is possible. In reality, one-to-one accounts mapping cannot be performed due to core differences of the accounting principles between corporate policy and local policy. E.g., in Russia there is no such concept as "Change in Stock". In Russia, all the purchases of materials and assets go always to Balance Sheet first, and then they are activated in Profit and Loss Statement when those materials are used or disposed. Change in Stock concept assumes your purchases go immediately to Profit and Loss Statement, then they are balanced by change in the same P&L and the ending stock goes to the Balance Sheet.

The ending financial result for both cases will be the same, but the way how it has been achieved in terms of accounting transactions is different, and can't be achieved by one-to-one mapping of same accounts.

• Such cases are usually resolved by creating additional management reports using Account Schedules or customized add-on solutions (e.g., Awara IFRS Reporter), when you will create a mapping set with complex rules where many-to-one relationship between Russian accounts and corporate accounts is established. Building a report would allow you to see the corporate accounts with figures on them, plotted according to the mapping logic.
• Another option, yet most heavy, is to build up a parallel accounting, where you will have a second CoA, in separate tables, with separate G/L Ledger entries, filled in with transactions of corporate accounts on an automated basis using mapping rules, stored additionally.

So, you need to carefully plan your CoA in advance, as correct structure will allow you to match both legal requirements and common practice, and simultaneously make your corporate reporting more efficient and less time-consuming.