> 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.