Tag Archives: correspondence accounting

The Illusion of Remote Control

Share

Many years ago I undertook a short consulting assignment in Kazakhstan on behalf of a small oil company based in London. There’s almost nowhere I wouldn’t visit at least once (except, perhaps, Baghdad) and I looked forward with great excitement to the trip. The oil company’s administrative offices were based in Aktobe, a town northeast of the Caspian Sea on the imperial-era Trans-Aral railway line. The oil field itself, I understand, was a few hundred miles southwest across the steppes towards the Caspian.

It wasn’t easy to get there. I flew from Prague through Moscow, and returned through Astana, Almaty and Istanbul.

aktobe map

I was invited to visit Aktobe to find out how the company was using SunSystems. Infor’s SunSystems is a British financial accounting system that, better than almost any other system of its type in the world, enables both local statutory accounting and corporate financial reporting to international standards. When it comes to remote financial control of an organisation, and Aktobe is nearly as remote as you can get and still find a four-star hotel, there is no better solution.

The company had just bought an oil field in the north of Russia and was considering implementing SunSystems near Archangel. They’d heard about us through our Moscow office and the British financial director seemed to place some trust in our company (LLP Group), or at least in me, probably because I am British too. How better to start with SunSystems in Russia than to look at how the company was (successfully) using the system in Kazakhstan?

Aktobe was built in imperial times, but bears all the hallmarks of a mid-sized brutal Soviet city – a simple grid of crumbling concrete apartment blocks, and wide wind-swept boulevards decorated with crude socialist realist monuments. In fact the city is less Russian now than for a hundred years, many of the Russians having left after Kazakh independence. A vast new mosque reflects the revival of local religion and culture, but in all other respects the city might have been anywhere in the former Soviet Union.

aktobe mosque

aktobe2

aktobe3

What persists, however, as in many former Soviet Republics (Moldova is another example) is Russian-style correspondence accounting (see Correspondence Accounting – The Russian Way of Debits and Credits) and most organisations in Kazakhstan use 1C, a Russian accounting software system that does Russian accounting excellently.

SunSystems has many advantages over 1C. It is more easily audited, it allows more analysis, and, crucially for international organisations, it enables statutory and corporate accounting in one system, with the relationship between the two definable and auditable. That’s why many international organisations use it in Russia and the former Soviet Union.

It was no surprise to me, though, to find, when I got to Aktobe, that my client’s accounting team were using 1C. Many companies keep two sets of books, one in 1C and one in a ‘Western’ system such as SunSystems. Sometimes they build a bridge between the two to ensure that the systems reconcile and to avoid wasting time in entering transactions twice. There’s often a debate about which system should be the ‘primary’ system, but I won’t bore you with that debate here.

The problem is that most local accountants find ‘Western’ systems uncomfortable and effortful. Whilst it’s perfectly possible to use only SunSystems in Russia (see SunSystems in Russia – Perfectly Possible for the Determined Amongst Us ), it’s less easy to derive statutory reports from SunSystems than from 1C, and all local accountants owe their primary loyalty to the state. This is entirely understandable. They are personally and criminally liable for their mistakes.

It’s not often, however, that hostility towards a ‘Western’ system is overt. The great surprise in Aktobe was that my client’s accounting team weren’t using SunSystems at all. They hated it, and told me so. They were sending their monthly financial reports to London, ostensibly derived from SunSystems, but in fact derived from 1C with a few adjustments here and there. I looked at the SunSystems ledgers and the latest journals were posted months and months earlier.

Remote control isn’t easy. As LLP Group has grown over the last twenty years I’ve seen how hard it is to maintain standards, whether they are ethical standards, HR standards, accounting standards or consulting standards. There’s no substitute for frequent visits, frequent training, frequent fraternising and frequent forensic investigations into what’s going on. Saying that something ‘must be so’ from a distance without ensuring it’s actually so, is a waste of time. It’s very hard to maintain remote control of a very faraway place, and it’s easy, in a faraway place, to deceive someone at headquarters whom you hardly know.

The client was excited by my findings and was ever more determined that they should abandon 1C in Aktobe, and that they should use SunSystems for their new oil field in northern Russia. They were properly alarmed by the fact that their financial statements, the basis for their stock-market valuation in London, were produced without much accountability, in Excel.

But then, just a few weeks later, another company bought them, and all projects were off. I doubt that the team in Aktobe ever posted another SunSystems journal.

 

SunSystems in Russia – Perfectly Possible for the Determined Amongst Us

Share

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).

russia

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.

1C

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)!

Correspondence Accounting – The Russian Way of Debits and Credits

Share

Have you ever heard of correspondence accounting?

If you’re not an accountant, or financial systems consultant, stop here. And if you’re an accountant and you’ve never had to debit or credit your accounts in Russia or the Russian-influenced world then you won’t need to know about this either.

Correspondence accounting is the Russian way of accounting, and it’s the bane of ‘Western’ financial accounting systems and of companies like mine, since we struggle to make the systems we sell work in Russia. My company, LLP Group, works with SunSystems, a British-born financial system that works more easily than most systems almost anywhere in the world  Indeed, we’ve implemented SunSystems for international companies in the USA, South America, Asia, Africa and Europe, ensuring a consistent view of finance even if local rules differ markedly.

But Russia is more difficult (any surprise?), and I write this in the hope that someone can tell me WHY!

Most accounting systems have a chart of accounts that lets you debit and credit to any series of accounts as long as you end up with a balance of zero. So you might do this for a sales invoice:

DEBTOR          1,000   D

SALES              800 C

TAX                   200 C

You can have any accounts in your journal, and any number of them (two credits and one debit in this case) as long as the final journal balance is zero.

But in Russian correspondence accounting each debit must be matched by a credit, and the two accounts involved must ‘correspond’. Indeed, the state issues a list of accounts that are permitted to ‘oppose’ each other. A Russian journal would look like this:

DEBTOR                1000 D                    SALES                 1000 C

VAT ON SALES    200 D                      VAT                      200 C

Each line, debiting a single account and crediting a single account must balance.

Most financial systems can imitate this style of accounting by imposing constraints on the way traditional journals are structured, but the real difficulty arises when you try to construct your statutory reports, since these rely on the corresponding account being known for every debit or credit. There’s even a kind of cross-reference report, a vast table, showing the values that have been posted between corresponding accounts. Statutory auditors, when not soliciting bribes, need only glance at this table to determine if the rules have been broken, and if fines are therefore due.

auditors

A small team of Russian auditors

All this is possible in ‘Western’ financial systems and in our company we’ve worked out a method that makes it possible. But it means that implementation time is longer and more expensive.

What is it all for? Who benefits? What possible management benefit comes from all of this? What statutory benefit?

Can someone tell me?!

And then there are ‘negative’ credits and debits!