npo-accounting-ikiwiki/UseCases/MultiCurrency.mdwn

# Supporting Multiple Currencies

Most modern accounting systems offer some sort of support for multiple
currencies, but the details of how it is done matter greatly, as lack of
flexibility in how multiple currencies are supported can render the feature
useless to some organizations.

There are roughly two operating modes that I've observed in use by non-profit
organizations.

## A "One Native Currency" Organization

In the USA at least, and perhaps elsewhere, the native currency to the
location of the entity is treated as the "one true currency" (which the USA
IRS calls your "functional currency") of the organization.  Specifically in
the USA, the IRS makes
[the following recommendation regarding currency conversion](http://www.irs.gov/Businesses/Small-Businesses-&-Self-Employed/Foreign-Currency-and-Currency-Exchange-Rates):

> Make all … determinations in your functional currency.  If your
> functional currency is the U.S. dollar, you must immediately translate into
> dollars all items of income, expense, etc. (including taxes), that you
> receive, pay, or accrue in a foreign currency and that will affect
> computation of your income tax.

(While this advice is specifically in the "small businesses" section of the
IRS website, it can be reasonably assumed that the IRS would apply a similar
rule to non-profits.)

As such, the accounting system that supports multi-currency should allow for
the handling of this rule.  Most non-profits simply do the currency
calculation "off book" and enter the USD determination into the system.  What
[Conservancy](https://sfconservancy.org) does, which probably makes sense for
our system, is to store a fixated rate, based on the prevailing exchange rate
for the currency on the date of the transaction.  (Conservancy, which
currently uses Ledger-CLI, uses Ledger-CLI's
[fixated prices feature](http://www.ledger-cli.org/3.0/doc/ledger3.html#Fixated-prices-and-costs)
to implement this).

The primary advantage of this method over an "off book" calculation is that
while you don't lose the detail that the transaction actually occurred in a
currency other than the organization's functional currency.

### Handling End-To-End Transactions In Non-Functional Currencies

If this representation system is chosen, the problem occurs in situations
where an entire sequence of related transactions -- from accrual to payment
-- must occur in a currency other than the organization's functional
currency.  The easiest example is a traveler who lives in Europe books a
flight in EUR, and seeks to be reimbursed in EUR, but the organization's
functional currency is USD.

In this case, again, the entire EUR-side of the transaction can be done "off
book", and the balancing amount at reimbursement time can be recorded simply
as a currency conversion expense (or income).  This again has the problem
that the detail of what actually happened is never recorded in the books.

The suggested way of solving this problem is to take the amount of EUR that
was fixated at a specific USD conversion rate at the time of accrual, and
then consider it to be "sold" at whatever the available exchange rate that
occurs.  (Again, Conservancy solves this with Ledger-CLI and
[a mix of the fixed lot prices and fixated cost feature](http://www.ledger-cli.org/3.0/doc/ledger3.html#Fixing-Lot-Prices)).

### Simplicity In Functional Currency

If an non-profit organization has a single functional currency, then most
aspects of the system, such as [[reporting|GeneratingReports]], can (and, in
fact, should) be done only in the functional currency.

---

## A "Multi-Native Currency" Organization

Multi-currency support is more complicated if an organization considers more
than one currency to be its native currency, which means that
[[reports|GeneratingReports]] must handle multiple currency.

FIXME: It would be useful if someone who has run an organization that has
more than one functional currency could describe the use cases on this issue.

---

## Choosing an Exchange Rate

Regarding exchange rates,  the
[USA IRS has no official policy on exchange rates](http://www.irs.gov/Individuals/International-Taxpayers/Yearly-Average-Currency-Exchange-Rates),
stating:
> The Internal Revenue Service has no official exchange rate. Generally, it 
> accepts any posted exchange rate that is used consistently.

> When valuing currency of a foreign country that uses multiple exchange
> rates, use the rate that applies to your specific facts and circumstances.
> For example, if you have a single transaction such as the sale of a
> business that occurred on a single day, use the exchange rate for that day.
> However, if you receive income evenly throughout the tax year, you may
> translate the foreign currency to U.S. dollars using the yearly average
> currency exchange rate for the tax year.

Given this IRS recommendation, it may make sense for the system to allow a
pluggable exchange rate system based on local policies of the organization.