Managing Multi-currency Accounting

Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 73

About the Company¶

Electronic Data Systems (EDS) was originally an independent U.S. company, but is now a wholly owned subsidiary of General Motors; it provides many services, including software and hardware, integrated systems, communications facilities, and manufacture of various electronic systems. The company has many mainframe sites around the world, linked into a major network, and it also operates client mainframe sites on contract.

The larger part of EDS (about 45,000 employees) deals exclusively with North America, but all other international business is handled by EDS International (about 5,000 employees) which has its HQ in London. Although EDS’s largest client is GM itself, it has a large and growing list of external clients, including industry, commerce, banks, airlines, governments etc.

B.O.S. - Budget and Outlook System¶

For accounting purposes, EDSI uses the well-known MSA (Management Sciences of America) multicurrency accounting suite. This is run under CICS on an IBM mainframe, and is used both for internal accounts and as a service for external clients. Taking the former, all EDSI account transactions worldwide go to the MSA accounts receivable or payable, and then to the General Ledger. Cost centre totals for the day are then sent to BOS by overnight batch file, and are held in BOS for the current month and 36 months historically.

The ‘budget’ is a normal January - December monthly budget which remains fixed for the year from January 1st. Because a fixed annual budget can soon get out of date for volatile accounts, BOS also provides an ‘outlook’ system; this is a forward rolling budget which always covers 12 months ahead, and which account managers can update each month.

BOS (like MSA) incorporates a hierarchical coding setup which defines how cost centre totals are to be aggregated up the various levels of the company structure (department, region, country, division etc.). The system also allows for expenses accruing in overhead cost centres to be allocated according to rules (which can be adapted) to the direct expenses of contract cost centres. Essentially, BOS calculates revenue, expenses, gross contribution and pre-tax profit, plus many intermediate quantities, at both cost centre level and any or all of the levels above - right up to the company total.

At the lower levels, results are available in either local currencies or US Dollars, but when aggregating above country level, all results are in a common currency, e.g. dollars. With time-series data, changes in exchange rate can distort comparisons, so the system also holds ‘restated’ amounts (i.e. converted to a common exchange rate) to give more appropriate time-series comparisons.

BOS is a menu-driven full-screen APL system, with 100+ screens nested up to 5 deep. In EDSI, all account managers have to use it, and there are currently some 400 users worldwide. A variety of results are available: the month-end ‘close’ report gives a detailed summary of the month’s business; there is also a large selection of comparisons with budget or outlooks; rolling totals, year to date etc. plus various projections. Data is available either by display (in many cases graphically) or print, or can be downloaded to PC spreadsheets.

Since the underlying MSA data which feeds BOS also satisfies the statutory accounting requirements of the host countries, the company is assured that its financial reporting is completely self-consistent across all levels of management.

In passing, I would like to make a brief mention of the EDS dress and conduct code, since many hold the outmoded idea that this is very rigid and militaristic. Although there may have been some truth in this historically, it is certainly not the case now; working conditions are exactly what you would expect in any major company dealing with outside clients, and people are very friendly at all levels.

An excellent point in EDS’s favour is that it has no age restrictions on employment, which has meant that I have been able to obtain a full-time job using APL at only a few years short of normal retirement age!

APL Aspects of B.O.S.¶

Written originally in IBM’s VS APL, it is now running under APL2, and some of the language enhancements are being found very useful. For example the hierarchical node linkage is conveniently held as a nested vector of numeric vectors. Other nested arrays are being used to simplify slabs of arithmetic, as well as to group together variables so as to minimise the (undesirable) use of semi-globals. The new TIME function under release 1.3 is excellent for code optimisation.

Each end-user’s data is different, and this is presently stored as sequential (QSAM) files; there can be thousands of these, giving a heavy I/O load. Work is in hand to replace these with a very large VSAM file, using an EDS-written assembler routine for file compression. This is expected to show substantial savings. (Have you looked at AFM? Ed.)

We also intend to use the new ‘packaged’ workspace facility, and have installed Release 1.3 to do this. However, initial tests showed that for overnight batch consolidation runs the CPU time was sometimes increased by up to 30%. This was quite unexpected, and IBM are investigating as a matter of urgency. The problem may be due to heavy file I/O, but other users of Release 1.3 would be well advised to do some careful timing on intensive applications.

BOS is by no means static, and further work is planned. Internally, we plan to use DB2 to simplify some of the fairly complex relational aspects. We are also likely to move towards downloading BOS calculations to the PC, using the mainframe only as a file-server and for batch work. In terms of function, the end users keep asking for new features to be added.

Finally, why APL? (APL is not in widespread use within EDS.) A few years ago, most of this work was done in ADRS spreadsheets, and then on PC spreadsheets. However the inadequacy of PC spreadsheets for heavy calculation soon became clear. Fortunately, an embryonic budget system in APL (originating from GM in Germany) already existed, and it was decided to build on this, starting in 1986. The users were given a functional system quite quickly, and this has been extended and improved quite rapidly. The managers who ‘own’ the system have all sorts of housekeeping utility screens to maintain user-tables, hierarchy tables etc. They are also quite happy to have simple changes put in place overnight, and not to have to wait too long for bigger things.

Well, that’s APL, isn’t it!