tutorial on multi-currency accounting

[Mike Alexander]

--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 
currency is the Euro.  Also, to simplify talking about this a bit, 
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 
GnuCash file for this can be downloaded at 
<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