Topics

First Steps

Applications that support only one currency need to be adapted to record the currency along with the amount. Simple to say, but this can be a substantial effort to modify the database schema and all applications that reference the data, and all code that has the currency hardcoded (i.e. programmed directly into the software as a particular currency rather than looking up the currency associated without the amount.)

In addition, when redesigning the software to accommodate different or multiple currencies, the designer should be careful as to which aspects are determined either by user preference (which may in turn be indicated by locale ), by regulation, by the nature of the application, or perhaps by other factors. The appropriate determining value(s) will need to be a part of the API. For example, the user may decide which character is used to separate the integer portion of a number from the fractional portion. That choice can be applied to the formatting of all currencies. On the other hand, a check printing application may have different requirements for formatting currencies from an application that lists financial transactions in a table. Regulations may determine how conversions are performed and how many significant digits are maintained throughout the calculations, which may in turn affect the display. (You don’t want to display more digits than are significant.) Different programming models will use different approaches to communicating requirements thru the architecture (procedural, vs. object oriented, etc.)

Requirements for Multiple Currencies

A common misconception is that only one currency is desirable for any account. Although, this is more true in North America, it is not the case in other regions. For example, if you ask an american bank for an account that has both concurrent Canadian Dollar (CAD) and American Dollar (USD) balances, you will likely be given 2 separate account numbers. However in Europe, it is common that one account can have multiple currencies in the same way that one brokerage account can be used to buy multiple stocks.

Regulations for Foreign Exchange

Regulations of course vary by country. Some relevant organizations are listed in the Links section. Depending on your country, you may need to process multiple currencies in compliance with one of:

• FASB Statement no. 52, Foreign Currency Translation ,
• Statements of Standard Accounting Practice 20 (the United Kingdom and Canadian authoritative pronouncement),
• International Accounting Standard 21, Accounting for the Effects of Changes in Foreign Exchange Rates (the IASC’s authoritative pronouncement),
• the European Community EC Directives 4 (Annual Account of Certain Types of Companies) and 7 (Council Directive on Consolidated Accounts), or
• other.

For an interesting matrix of foreign exchange features and accounting products, see Accounting Software Advisor, LLC article. (Some Progress ISV’s mentioned.)

Foreign Exchange (FX) rates

Foreign Exchange or FX rates can be confusing. There are spot, forward, cross and other FX rates. You also need to be careful with how rates are quoted. The CAD/USD rate can be quoted in terms of CAD (eg. 1 CAD = .6 USD) or in terms of USD (eg. 1 USD = 1.5 CAD).

Many good systems allow users to enter Exchange Rates as needed. Some companies enter a default rate per month, and others have live feeds that enter rates as they change during the day. Note that many financial transactions are not instantaneous. As currency exchange rates fluctuate, the timing can be significant. Programs must be careful to acquire the exchange rate for the right date and time. Transactions that spread payments over time (sometimes years) may require multiple exchange rates.

Reports by currency

Multi-currency users will not be satisfied to simply sort reports by a single currency. For example, a list showing account and balance in USD, immediately followed by account and balance in CAD, followed by more USD, then more CAD, etc.

Instead, column totals should be divided into CAD and USD, with a final total converted to the local currency. This can be complicated to program, especially if there are many currencies involved.

Rounding

Rounding in financial applications must follow local regulations. You may have learned the following rule to round numbers with fractional portions:

• If the last digit is less than 5, drop it. Otherwise,
• If the last digit is equal to or above 5, add one to the previous digit and drop the last digit.

By these rules, 6.011 rounds down to 6.01, and 6.015 rounds up to 6.02. However, these rules are not always appropriate in the financial world.

(The following rounding examples are based on Software Internationalization and Localization: An Introduction by Uren, Howard and Perinotti, Van Nostrand Reinhold, September 1993 ISBN 0-442-01498-8. page 27.)

For example, in Argentina rounding is prescribed for the third digit after the decimal point:

• If the third digit is less than 3, change it to 0 or drop it. Otherwise,
• If the third digit is both greater than 2 and less than 8, change it to 5. Otherwise,
• If the third digit is greater than 7, add one to the second digit and drop the third digit or change it to 0.

Argentina Rounding Examples