Handling multiple currencies in GnuCash

Question

I started using GnuCash when I used in Germany and hence I have a whole EUR structure in my database (Aktiva, Anfangszustand, Aufwendungen, Ertraege, Fremdkapital).

Later, I moved to the US. I created a new gnuCash database for that (US Assets, US Equity, US Expenses, US Income, US Liabilities). However, soon I found that this is not optimal because I would buy stuff for the US with my EUR accounts and vice versa. After a couple of months I merged my two files and since then I have hierarchies in both US and EUR and I feel this is a mess.

My question is: What is the recommended way to organize the hierarchy?

Does it sound good to have both in parallel? Or would it be better to a common "Assets", "Expenses", "Income", "Liabilities" and "Equity" container and move all accounts underneath it? Would I use EUR or USD for the top level account?

I somewhat find the second approach appealing but I am not sure if I that's the right thing to do.

Finally, from travelling, I have some hash in other currencies that I track with gnuCash. Currently I have them under "Aktiva" (which is EUR) as "Cash (AUD)", "Cash (Swiss)", "Cash (Turkey)" etc. But this seems random to me. What is the proper way to organize this?

Answer 1

Use your current country of residence as the primary:

We summarize the main points of the SSAP 20 method:

There is always one special reference currency, typically "the company's local currency". All accounts are kept in the reference currency. Tallies in non-reference currencies are only informational, and do not take part in balancing. Fluctuations in the relative values of non-reference currencies are reflected immediately in their corresponding asset accounts (and also in a currency gain/loss account).

The advantages of this method are: Since all entries are in one currency, no special software support for multiple currencies is needed — in principle, only single-currency accounting software is required. The accounts are balanced.

The disadvantages are: Separate "tallies" of foreign currencies and their exchange rates must be kept (the green columns in the examples). In fact, these "tallies" contain original (source) information, whereas the corresponding asset/liability accounts contain derived (calculated) information. In a sense, the foreign currency accounts that are kept in a local currency are only "virtual" accounts, whose contents are entirely calculated. Accounts must be re-valued periodically, and the question arises when to do this. In principle, this should happen just before every transaction, and just before generating a report. If there are many foreign currency accounts, this can mean a lot of (manual) work. It is relatively difficult to add or change a transaction retroactively. If a new transaction is entered for an earlier date, then all future currency gains and losses must be recalculated. This changes future transactions, not just future balances. There is an unsatisfying asymmetry in this accounting method, because one currency must be given prominence above all others.

The first three of these disadvantages can be alleviated by using software that supports the SSAP 20 accounting method. In this case, the user only has to enter the data from the green columns, and the software is able to take care of conversions, re-valuations, and calculating the corresponding gains and losses.

Then use the price editor for each foreign account:

References

• Peter Selinger: Tutorial on multiple currency accounting

• GnuCash: Stock and Currencies – Flameeyes's Weblog

• GnuCash Docs: Chapter 12. Multiple Currencies