Multiple currency accounting in GnuCash

Author: Peter Selinger <selinger at users dot sourceforge dot net>
Written: Jun 4, 2005
Last updated: Feb 22, 2007

Note [Oct 27, 2010]: The information on this page is outdated. Support for multi-currency accounting, as described in the Tutorial, was added in GnuCash 2.3.9. This hopefully means that it will also be included when the next "stable" GnuCash 2.4 is released.
This feature is not enabled by default, and must be turned on explicity. To do so, check "Use Trading Accounts" under File -> Properties -> Accounts. This must be done on a per-file basis. Thanks to Mike Alexander, who implemented this feature in 2007, and worked for over 3 years to convince the GnuCash developers to include it.
There isn't yet a lot of documentation of the new feature; one day I plan to update this page with new screen shots etc. For now, I have kept the below information for historical reference.

   0. Introduction
   1. Single-entry foreign currency accounting in GnuCash
   2. Double entry foreign currency accounting, the wrong way
   3. Accounting vs. reporting
   4. How to do SSAP 20 accounting in GnuCash
   5. How to use currency trading accounts in GnuCash,
   6. Automating the process
      6.1. Changes to the GnuCash engine
      6.2. Changes in the user interface
      6.3. Example
   7. "Currency trading accounts" in older GnuCash versions
   8. Translation issues

0. Introduction

This document is a supplement to my Tutorial on multiple currency accounting. While the Tutorial deals with multi-currency accounting in general, this supplement deals with issues specific to the GnuCash accounting software.

This document attempts to explain how to do (and how not to do) multiple-currency accounting using GnuCash. It explains how GnuCash handles multiple currencies in single-entry and double-entry accounting, and points out some of the flaws in the GnuCash built-in currency support. It shows how one can work with currency trading accounts "by hand" in GnuCash. Finally, this document comments on possible changes to GnuCash that would make its multiple currency support more useful.

Before reading this document, you should read the Tutorial, which explains the basic concepts of multi-currency accounting.

Unless noted otherwise, the examples below refer to GnuCash version 2.0.5, which is the current version as of this writing.

1. Single-entry foreign currency accounting in GnuCash

Multi-currency support in GnuCash is adequate for the purposes of the single-entry accounting method described in the Tutorial, Section 2.1. When entering a transaction involving accounts in multiple currencies, the user is automatically prompted for an exchange rate. In the single-entry accounting methods, imbalances are ignored.

The following screen shot show the example from the Tutorial, Table 2.1, done in GnuCash. (You can click on the image for a full-sized version).

Download this example: table2.1.xac.

2. Double entry foreign currency accounting, the wrong way

For double-entry accounting, the multiple currency model used by GnuCash is based on spot exchange rates. It is equivalent to the flawed accounting method illustrated in the Tutorial, Section 2.2.

To illustrate the fact that GnuCash really is not doing the proper thing, consider the following screen shot. It shows exactly the example from the Tutorial, Table 2.2, done in GnuCash.

Download this example: table2.2.xac.

The screen shot shows the CAD and USD cash accounts, the Food Expense account, and the accounts chart. Clearly visible in the accounts chart is the absurdity, also seen in the Tutorial, Table 2.2, whereby the current assets grand total is CAD 135, whereas the equity minus expenses is CAD 128.

3. Accounting vs. reporting

The current view of the GnuCash designers, as expressed in the document src/doc/currencies.txt, is that the computation of unrealized gains and losses should be handled by the report system, rather than the accounting system. I believe this to be a very bad idea.

In effect, handling currency gains and losses through the report system means that GnuCash accounts are inherently unbalanced. The report system is then expected to treat these imbalances as a currency gain or loss. This amounts to "Foreign currency accounting with adjustments" as shown in the Tutorial, Section 2.4, but it is bad accounting practice for the reasons discussed there. In particular, there is no distinction between imbalances that are due to currency trading, and imbalances that are due to arithmetic or data entry errors. Effectively, such a system is a step backwards towards single-entry accounting.

Also, in such a model, it is not possible to break down income and expenses by category. As a result, unrealized gains and losses cannot be classified into categories in the current GnuCash model.

One of the stated goals of the designers of the GnuCash foreign currency model, again according to the src/doc/currencies.txt, is to "eliminate the need for currency trading accounts". In my opinion, this is unfortunate, because currency trading accounts, if implemented properly, can be a very useful tool for tracking income and expenses.

Is the GnuCash report system able the handle unrealized gains and losses, as described in src/doc/currencies.txt? The following example shows that this is not the case. It is the "Balance Sheet" report, produced by GnuCash's report system from the above double-entry accounting example.

Note that it shows the same discrepancy between Assets, Equity, and Expenses: the total assets are CAD 135, whereas the equity minus expenses is CAD 128. So the model from src/doc/currencies.txt has not been implemented. [Update 2007/03/23: Mike Alexander wrote a patch that fixes this problem with the report system.]

4. How to do SSAP 20 accounting in GnuCash

SSAP 20 accounting, as described in the Tutorial, Section 3.2, works by translating everything into a single currency. Foreign currency assets and liabilities have to be manually re-evaluated at specific times, for example at the end of an accounting period, or to calculate unrealized gains and losses. However, these calculations are done "by hand" outside of the accounting software.

Since SSAP 20 accounting takes place in a single currency, no special software support is necessary. To handle this accounting method in GnuCash, simply use GnuCash as a single currency accounting system.

Of course, some of the tedious aspects of SSAP 20 accounting, such as re-evaluation of assets and liabilities, could benefit from some software automation. However, GnuCash does not currently offer such tools. If you have a lot of foreign currency transactions, you might be better off using currency trading accounts, as described in the next section.

5. How to use currency trading accounts in GnuCash, "by hand"

Multi-currency accounting with currency trading accounts is described in the Tutorial, Section 4.2. As discussed briefly in the Tutorial, Section 4.3, such an implementation is mathematically "compatible", by translation to a single currency, with SSAP 20 and similar accounting standards.

To avoid confusion, let me point out that some older GnuCash versions (such as 1.8.11) implemented something called "currency trading accounts". However, these accounts are not the same as the currency trading accounts described here, and they do not work properly. See Section 7 for further discussion.

The GnuCash engine is already reasonably well-equipped to handle accounts in multiple currencies, and will not mess anything up as long as you do not ask it to perform currency conversions. It is therefore possible to implement multiple currency accounting "by hand" in GnuCash. Here is how to do it:

Create a new top-level income account called "Currency". This account only serves as a parent account, and will not hold any transactions; it can therefore be marked as a "placeholder" account. The Currency account should be denominated in the report currency (in our examples: CAD).
For each currency that you wish to support, create a sub-account of the top-level "Currency" account. For example, if you are dealing with Canadian Dollars and U.S. Dollars, create the following two accounts:
Currency:CAD
Currency:USD
Each of these accounts should be denominated in its own respective currency. Here is how the corresponding portion of the accounts chart might look:
Now for each transaction that involves a currency exchange, route the currency exchange through the corresponding currency accounts. For example, consider the transaction of January 2 from the Tutorial, Table 4.4. It involves moving CAD 120 from the Canadian Cash account, exchanging CAD 120 for USD 100, and moving USD 100 to the U.S. Cash account. This transaction can be entered in GnuCash as follows:

Special notes:

The GnuCash user interface will prompt for some exchange rates, but these rates can (and should) be ignored. You may as well set all exchange rates to 1. Since you are doing multiple currency accounting "by hand", it is best not to let GnuCash's currency mechanism interfere.
The transaction is balanced in each currency separately. In effect, the entire transaction works as if there were two separate transactions: one to move CAD 120 from Canadian Cash to Currency, and another to move USD 100 from Currency to U.S. Cash. Therefore, exchange rates do not enter into the picture explicitly (however, you need to know the exchange rate to figure out the amounts you should enter).
The GnuCash user interface will often get confused, and leave exchange rates uneditable. Sometimes a transaction will show up correctly when viewed from one account, and all the entries will be blank when the same transaction is viewed from another account. This is a bug in GnuCash (bug #410604). There is currently no way around it, except to delete the transaction and start from scratch. [Update 2007/03/23: Mike Alexander wrote a patch that fixes this problem with entering multiple-currency splits.]
GnuCash translates all parts of a transactions to the currency of the local account. Thus, if you want to see the actual transaction amount in its source currency, you have to set all exchange rates to 1. This is an unfortunate user interface issue, due to the fact that GnuCash assumes that you are doing single-entry accounting.

Here is a complete example, based on the Tutorial, Table 4.4. Here is a screen shot that shows the accounts chart and the U.S. Dollar account (in transaction journal viewing mode).

Download this example: table4.4.xac.

Note how in the accounts chart, the total shown for the Currency parent account is CAD 7, showing precisely the income from currency gains. Also, at the bottom of the accounts chart window, the total expenses are accurately shown as CAD 65, which is the difference of CAD 72 in food expenses, and CAD 7 in currency gains.

This accounting method also works nicely with the report system. Here are the Income Statement and Balance Sheet for this example:

Again, note how on the Income Statement, the currency gain of CAD 7 is shown under Revenue. Together with the CAD 72 food expense, this results in a net loss of CAD 65 for the reporting period. On the balance sheet, the total assets of CAD 135 are balanced properly against equity minus losses.

6. Automating the process

Doing multi-currency accounting in GnuCash "by hand", as described in the previous section, is a very tedious process. It would be nice if GnuCash could automate some of the steps.

Here are some of the changes that would be necessary:

6.1. Changes to the GnuCash engine

Very few changes are necessary in the engine. It would be useful to have a switch for "strict multi-currency accounting", which makes the engine forget anything that has to do with currency conversions. The engine should still support different currencies, but should refuse to do any kind of conversion between them. Instead, it should check that every transaction is balanced in all currencies separately.

When strict multi-currency accounting is enabled, currencies should be attached to individual items in a transaction, and not to a transaction as a whole. In fact, they should only be attached to accounts. Anything to do with exchange rates is entirely a user interface issue and does not belong in the engine.

Perhaps it would be useful to have a special account type "Currency", which acts like an income account, but might be formatted specially by the report system, and which may be recognized as a currency trading account by the user interface. For now, the type "Income" can be used.

6.2. Changes in the user interface

By default, the user interface should automatically create a currency trading account, with the requisite sub-accounts such as Currency:CAD and Currency:USD, when the need arises.

Also, the user interface should be updated to use the currency trading accounts, doing as much as possible automatically (in fact, this can be done in a way that it is almost transparent to the casual user). For users who don't want to do double-entry accounting, single-entry accounting should still be an option, and in this case, currency trading accounts are not needed. But if the user chooses to enforce double-entry accounting, then the following should happen:

Transactions involving only accounts in one currency are handled as before.
If the user enters a transaction between accounts in more than one currency, a dialog window should pop up (as is currently the case). In addition to asking the usual questions about exchange rates, the dialog should now also ask: "Which currency trading account do you wish to use for this transaction?". If the user chooses no account, then a default account should be automatically used, and if none exists, then one should be created. (This is analogous to what happens when the user enters an unbalanced transaction, in which case GnuCash automatically offers to add an adjusting split (and automatically creates an imbalance account if none exists)).
A currency trading account simply consists of a placeholder parent account with a number of sub-accounts corresponding to the individual currencies.
The system should enforce that all transactions are balanced, not just with respect to the current exchange rate, but separately in each currency, as in the Tutorial, Table 4.4.

It might also be useful to augment the report system with a facility to print financial reports that are SSAP 20 compliant, i.e., reports that convert all balances to a single currency, and that automatically identify trade account balances as currency exchange gains and losses.

6.3. Example

Suppose the user wishes to enter the transaction of January 3 from the Tutorial, Table 4.4, i.e., to purchase food for USD 40 from the U.S. Cash asset account, entering a food expense of CAD 52 in the Food expense account. The user goes to the U.S. Cash account register, enters the date and description, chooses the Food expense account under "Transfer", and enters 40.00 in the "decrease" field, as shown in this screen shot:

When the user presses "enter", she is presented with the usual currency exchange dialog, except that it now also contains a field where the user has to pick an appropriate currency exchange account. (The following is not an actual screen shot, but a rendition of what the dialog might look like):

Finally, the transaction should be (automatically) entered as the following split transaction:

Note that, unlike the current user interface, transfers are displayed in this transaction together with their denominations. Also note that the Currency accounts should usually be hidden from the ledger view, i.e., the transaction of Jan 2, when viewed from the U.S. Cash ledger, shows "Canadian Cash", and not "--- Split Transaction ---", as the correspondence account.

With this accounting method, the exchange rate menu is simply a convenience that helps the user enter a complex transaction. However, the user has full flexibility to make changes to these transactions afterwards, in case the currency transactions have not been calculated as the user expected, or in case some more complex transaction is needed.

In the accounts chart, trading accounts should be shown together with the income accounts.

7. "Currency trading accounts" in older GnuCash versions

Older GnuCash versions, such as 1.8.11, used to support something called currency trading accounts (accounts of type "Currency"). However, these accounts are not the same as the currency trading accounts described in the Tutorial, Section 4.2.

In old GnuCash versions, transactions involving a currency trading account are immediately translated into a single currency, and only a single balance is kept in a currency account. For this reason, the currency trading accounts provided by GnuCash are incapable of calculating currency exchange gains or losses, and they do not respect the accounting equation.

To illustrate this, consider the following screen shot from GnuCash 1.8.11. It shows exactly the example from the Tutorial, Table 2.2, done using the "currency trading accounts" of GnuCash (which are not really "currency trading accounts" in our sense). You can click on the image for a full-size view.

The screen shot shows the general ledger, the USD trading account, and the accounts chart. Visible in the accounts chart is the same result as in the Tutorial, Table 2.2, namely, the current assets grand total is CAD 135, whereas the equity minus expenses is CAD 128. Therefore, there is an imbalance, despite the use of a Currency account.

8. Translation issues

One important issue that comes up in multiple currency accounting is translation, as discussed in the Tutorial, Section 6. Translation is different from accounting, because it is an operation at the level of reports. This happens when the annual reports of one company are translated to a different currency, for example for incorporation into a parent company's books.

Since translation is a reporting issue, it should be handled by the GnuCash report system. It does not affect the GnuCash engine at all.

Multiple currency accounting in GnuCash

Contents

0. Introduction