Home Guidelines Datetime Currency i18n Problems Practical Bits Quality

Simple guidelines for currency handling

Introduction

Processing and display of currencies are crucial functionality in many applications, for example, for purchasing, inventory control, accounting, etc. NOTE: Data types used in databases to store numeric values (aka. "amounts") associated with currency processing are outside of the scope of this document. Application design must follow customer industry precision and rounding standards.

Representation of a currency

In a software application, a currency can be represented in several ways:

Note: Obsolete or deprecated currency symbols and names must not be confused with the usage of the terms "obsolete" or "deprecated" in general coding. Obsolete currencies may continue to be around in records management, accounting, banking, etc. Codes, IDs, and names to use Use ISO 4217 currency names, alphabetic codes and numeric codes in software: http://www.iso.org/iso/support/faqs/faqs_widely_used_standards/widely_used_standards_other/currency_codes/currency_c odes_list-1.htm.

English names and codes used by banks can be found, for example, at http://www.lloydstsbcorporatemarkets.com/glossary/currencies.asp

A good source for additional obsolete codes is: http://en.wikipedia.org/wiki/ISO_4217 Applications may have to be able to use obsolete codes but this may cause additional translatability issues.

For the Euro see:http://ec.europa.eu/economy_finance/publications/publication6336_en.pdf

You can augment these with data from the Unicode CLDR project. If there is a conflict with ISO 4217, use ISO 4217 because this is what the money industry (banks, brokers, etc). uses. Major programming languages and API (for example, JAVA, Windows API) use ISO 4217.

Application designers must ensure that display names are unique. The best way to achieve this is to add the ISO 4217 alphabetic code to selection options.

Use this: US Dollar (USD)

Do not use this: US Dollar

As a matter of fact, there are three codes related to US Dollar: USD, USS, USN see ISO 4217 for details.

You can use currency symbols for display, for example, in an invoice: $ 40.47. However, currency symbols as labels by themselves MUST NOT be in translatable files.

Symbol handling:

Extract to untranslatable file: Yes

Extract to translatable file:     No, for eample, the yen symbol by itself: Y

Extract with context:                Yes, for example, the dollar symbol followed by the name: $ (US Dollar)
 

Currency and country

While a currency is often tied to a country, software applications will usually need to provide a way to configure the display and use of currencies.

Main reasons for the need to allow configuration:

Formatting currency values

The numeric values displayed to users must be formatted in accordance with the user's locale. The decimal symbol and the grouping separator must follow the user locale. Never enforce formatting based on your notion of what the "default" format based on the currency name would be. For example, USD 22,00 would be the expected format to use in Germany -- unless your user is on a US military base in Germany and adds up US postage.

Currency name and currency label

All displayed "names" of currencies must be treated as "labels" in terms of software design and coding. In other words, if a display in a dropdown contains "U.S. Dollar" and the user can select "U.S. Dollar", the actual selection must be based on a unique identifier that is not ""U.S. Dollar" but the numeric ISO 4217 value 840 or the ISO 4217 code USD.

General issues

Obsolete currencies can cause naming collisions. Given that storing user interface strings in a database is extremely common in enterprise software, you will almost certainly run into currency label issues at some point.

This is especially true if you place "constraints" on label columns solely for the purpose of checking that labels are unique. Since currency labels are generally exported to a file to get translations, checks for duplicate translations should be performed at the file level.

If duplicate strings (labels) cause an application runtime error, the initial application design is flawed.