SunSystems’ financial modules can adapt themselves to almost any statutory regime, but in some countries implementation is more difficult than in others. Probably none is more difficult than Russia (and all those other countries where Russian accounting standards apply).

What’s so difficult about it?

Isn’t it just a matter of capturing data and reporting it, just like everywhere else?

Yes, but it’s also a matter of defending yourself against the suspicions of statutory auditors.

First of all there’s a statutory chart of accounts. You must decide very carefully whether this will be your primary chart of accounts, with each local account mapped to a corporate account, or whether it’s better to do it the other way round.

Then there’s the issue of ‘correspondence’. Every debit must have a corresponding credit. So when you book a sales invoice you must book it this way:

Debit DEBTOR account, Credit SALES account,

Debit DEBTOR account, Credit VAT account.

The DEBTOR account is the corresponding account both for the SALES account and the VAT account.

‘So what?’ you might ask. That just means a few more debits and credits than you would usually post to your ledger. The overall balances will still be the same.

True. However, the problem, such as it is, lies in the reports you must show when you’re defending the correctness of your ledgers to a statutory auditor. An auditor may ask for a cross reference or tabular report that shows all the correspondences between accounts – debited accounts on one axis, credited accounts on the other. And woe betide you if there are some debits or credits between accounts that are NOT ALLOWED to correspond.

SunSystems cannot, itself, produce this kind of report, even if you’ve taken the trouble to record the corresponding account for each debit or credit in a transaction analysis field. There are some commercially-available add-on programs that can determine correspondence and produce the cross-reference report by following the relationships established within each journal, as long as debits and credits individually balance, but it’s not straightforward.

Then there are the negative debits and credits.

And there’s the obligation to submit your statutory reports using XML.

SunSystems wasn’t initially designed with Russian accounting in mind, though  SunSystems’ Extended Analysis concept certainly helps with statutory reporting. The issue is a profound one. SunSystems is a ‘Western’ accounting system, like all the others that you may be familiar with, such as SAP and Oracle. All ‘Western’ systems struggle to manage Russian accounting rules and conventions with ease. At best they mimic the home-grown systems that were created specifically to meet Russian standards. Foremost amongst these is 1C, which almost every company in Russia and in the countries of the former Soviet Union (Kazakhstan, Moldova, etc.) uses. It’s regularly updated as statutory reporting changes, and it works more or less straight out of the box. The XML reporting formats defined by the state are exactly those that 1C produces.

And yet, 1C doesn’t easily serve corporate reporting and management accounting needs, and often doesn’t even meet ‘Western’ corporate auditing standards in terms of controls on journal modification, period closure and so on.

So, when implementing SunSystems in Russia, you have a number of choices:

Implement ONLY SunSystems.

• Your local accounting staff won’t like this. It’s harder work for them to construct the reports that 1C would do at the press of a button.
• You’d be well advised to enter the corresponding account on every debit and credit using a T-code. Easy to make mistakes.
• You’ve got to use some specially written software to create a cross reference report if someone asks for it.

Implement BOTH SunSystems and 1C.

• You’ve either got to enter every transaction twice, or
• You’ve got to build an interface from one system to the other to transfer the transactions

In the end it depends on your determination and on the flexibility of your local accountants. My experience is varied:

• I’ve worked on a SunSystems implementation for a large US consumer goods distributor where only SunSystems was used, and without the posting of ‘corresponding’ account into a transaction analysis field. A locally provided program was used for the construction of cross-reference reports and other statutory reports, as required.
• I’ve seen a SunSystems implementation at a hotel where only SunSystems was used, and a transaction analysis field was used for the posting of corresponding account.
• I’ve seen a SunSystems implementation where all transactions were additionally and separately recorded in 1C.
• I’ve seen a SunSystems implementation where all transactions were initially entered into 1C and then exported into SunSystems for adjustment.

None of these scenarios is straightforward, but all can work. LLP Group has been supporting SunSystems in Russia through its Moscow office for nearly twenty years. If anyone can help, we can. See more on our approach to global SunSystems implementations on LLP International.

One last but important point: don’t for a moment think that you can ignore Russian reporting requirements and just accept whatever sanctions might follow. That would be a very foolish choice (see High Inflation)!