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.
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
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
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
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
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
5. How to use currency trading accounts in GnuCash,
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:
Each of these accounts should be denominated in its own respective currency. Here is how the corresponding portion of the accounts chart might look:
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:
A currency trading account simply consists of a placeholder parent account with a number of sub-accounts corresponding to the individual currencies.
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
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
Since translation is a reporting issue, it should be handled by the GnuCash report system. It does not affect the GnuCash engine at all.