# tutorial on multi-currency accounting

Mike Alexander mta at umich.edu
Thu Mar 8 18:29:40 EST 2007

```--On March 8, 2007 3:56:43 PM -0500 Derek Atkins <warlord at MIT.EDU>
wrote:

> Quoting Peter Selinger <selinger at mathstat.dal.ca>:
>
> A single transaction by itself is neither a gain nor a loss.  It's a
> POTENTIAL gain or loss, but not by itself..  I guess that's why I'm
> so hesitant to embrace this idea.  Here's an example.  I'm traveling
> abroad and go to an ATM and pull out ?100 out of my US Bank Account.
> (later on I find that this ?100 cost me \$157.23).  That's it.  There's
> this single transaction.   Do I have a ?100 Income?  I dont think so.
> Do I have a ?100 Expense?  I don't think so, either.

You didn't say, but suppose for the sake of argument that the foreign
let's ignore non-currency commodities.  They don't complicate the
implementation much, but the do complicate the discussion.

After that transaction (with the changes we're talking about) you'll
have two additional splits in this transaction.  One will be a debit to
the Currency:EUR account and the other will be a credit to the
Currency:USD account.  If the exchange rate never changes then the
balance in the parent Currency account (converted to either USD or EUR)
will be and remain zero.  No income, no expense.

If the exchange rate changes (and no additional transactions are
entered) and you update the price DB accordingly, then the balance in
the Currency parent account may be non-zero.  Since the child accounts
are not all in the same currency at least one will have to be converted
into a different currency to get a balance in the parent account and
the changed exchange rate affects this conversion.

> This is why I think it's Equity.  I now have an Equity balance of
> ?100. Where did this ?100 come from?  Well, it came from the exchange
> of \$157.23...  But it's neither an income nor an expense.

At that point the balance in the currency trading accounts (absent
exchange rate changes) will be zero.  They are still income accounts,
however.  It's confusing, perhaps, because these accounts represent
potential income which is odd.  Peter suggested creating a new account
type for this purpose separate from the income account type.  This
doesn't really affect the fundamental problem, but it might make things
less confusing.

> Now let's say I buy a ?2 candy bar.  That's an expense.  But what if
> I go to my friend and sell that candy bar for \$5 (he's REALLY
> hungry!). See, this can get infinitely complicated.  So let's
> constrain the problem.
>
> Let's say that I take those leftover ?98 and exchange them for
> \$145.76. I certainly don't have a loss of \$11.43 (because I bought
> that candy bar).

Of course not.  This is essentially the same as the Table 4.4 example
in Peter's document
<http://www.mathstat.dal.ca/~selinger/accounting/gnucash.html>.  The
<http://www.mathstat.dal.ca/~selinger/accounting/table4.4.xac>.  Rather
than me trying to explain it all again here, why don't you go take
another look at those?  Peter did a better job than I can of explaining
it.  It really does work, and (at least to some of us) it makes a lot
of sense.

> As soon as you say "trading accounts" this again brings up the
> description of the old "Currency" accounts which are what you needed
> to do to trade from one currency to another.
>
> I'll point out that the CoA never balances, either.  A - L never
> equals your Equity in your accounts (until you include Income and
> Expense, but most people don't think about that).

Maybe, but the GnuCash documentation says (correctly, I think) that

Assets - Liabilities = Equity + (Income - Expenses)

Peter used different names for these in his tutorial, but the effect is
the same:

Assets - Liabilities = Capital + Income - Expenses

That's the correct accounting equation, I believe, no matter what
people may think, and it would be nice if the GnuCash accounts obeyed
it after scrubbing all transactions.

> Having the reports do some of the heavy lifting is PERFECTLY
> reasonable.

Perhaps, but it seems better to me for the accounts to be balanced
automatically without having to run a report to see whether they are or
not.  However, if most people think the current scheme, where the
accounts are internally unbalanced, but the balance sheet report
adjusts for that is better, then that won't be the end of the world.
In this case I would, however, suggest that my patch to make the
balance sheet report actually do this should be applied.  Right now the
balance sheet report does not correctly adjust things.

In the meantime, I think I'm going to continue working on this since I
still think it shows promise.  Even if it turns out to not be useful to
others, I may still use it myself.

Mike

--
Mike Alexander           mta at umich.edu
Ann Arbor, MI            PGP key ID: BEA343A6

```