Changeset - 9d639b974ff0
[Not reviewed]
0 0 1
Bradley Kuhn (bkuhn) - 8 years ago 2013-11-13 18:17:25
bkuhn@ebb.org
First draft of MultiCurrency use case.
1 file changed with 95 insertions and 0 deletions:
0 comments (0 inline, 0 general)
UseCases/MultiCurrency.mdwn
Show inline comments
 
new file 100644
 
# 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.
0 comments (0 inline, 0 general)