Multi Currency Accounting

Multi-Currency Accounting

Multi-currency accounting is a purely reporting level problem. Depending on how the user wants to summarize information, different methods can be used, but the data stored in the transactions themselves does not change.

Unfortunately for us, multi-currency accounting is an extremely complicated part of accounting. The mechanics of it are simple enough to describe, but the impacts of it on reporting increase the complexity of the calculations exponentially. At the same time, because this is so complicated, many accounting software (especially new startups) ignore it, or leave it up to the accountant to do the hard work themselves. This is an opportunity for Financica that can be exploited.

Summary

1. Multi currency accounting is tough
2. We should worry about capturing rates when creating and updating transactions
3. We should worry about the impact of this on reports when calculating the reports.

Perspectives

There are three perspectives on multi-currency accounting that we need to consider.

1. Financial reporting impact - what do the accounting standards say about dealing in foreign currencies?
2. Tax impact - what does tax law say about dealing in foreign currencies, in terms of income tax or VAT?
3. Business impact - what do business owners want to see when it comes to foreign currencies?

Because multi-currency accounting is a reporting level problem, we can easily treat each perspective individually in the app.

Accounting standards

In general, accounting standards require firms to choose a primary currency. All transactions that occur must be translated into that primary currency. This primary currency is supposed to represent the currency that most of the transactions require.

Revenue and expenses are translated on the date of the transactions. Assets and liabilities are translated on the date of the statement. This makes intuitive sense: If I own a bank account with EUR 10,000 and my primary currency is USD, the value to me of that account shifts over time. If the exchange rate worsens from 1 USD to 1 EUR to 1 USD to 1.5 EUR, the value of my bank account grows from USD 10,000 to USD 5,000. We can say that the account has been revalued.

If instead I paid EUR 10,000 in salaries when the exchange rate was 1 USD = 1 EUR, I received $10,000 in value. If the exchange rate changes to 1 USD = 1.5 EUR, the value of the salaries I paid for doesn’t change because I already received those services.

Therefore, revaluing only affects assets and liability accounts.

Revaluation

When an account needs to be revalued, a new transaction needs to be posted. If I need to increase the value of an asset account, we know there is a debit that exists (debits increase the value of an asset), and we know that a credit needs to exist as well. Where should the credit go? Accountants make use of a special account for this: a foreign exchange gain/loss account.

DR EUR Bank Account                10,000
CR Sales Revenue                  (10,000)
Recording EUR 10,000 deposit

DR EUR Bank Account                 5,000
CR Foreign Exchange Gain           (5,000)
Revaluing EUR bank account

Foreign exchange gain/loss accounts are special because they exist to net changes in foreign exchange together. It is technically either a revenue or expense account, but in practice the balance can either be positive or negative. It is not exactly revenue though (your assets have appreciated in value but you haven’t done anything to deserve it) and it is not exactly an expense either (your asset has depreciated in value, but you haven’t done anything to deserve it). Therefore, it is usually included as an “other” income statement item, below revenue and expenses, and changes are net together. In essence, the foreign exchange gain/loss account balance represents the net impact of changes in the business environment that have affected your business, but are not related to operations.

Income statement items are not revalued and are recorded instead at the exchange rate on the date of the transaction. Therefore, revaluation entries are not posted for income statement items.

There is one trick to implicit in revaluation that should be considered. Let’s say we sell a service for EUR 1000 when our primary currency is USD and th

In Practice

When recording transactions in an organization with multiple currencies, we need to know some extra information when doing our bookkeeping. In addition to the usual suspects of invoice amounts, VAT, dates, etc, we also need to know the prevailing exchange rate. These are published by central rates on a daily basis.

In practice, accountants do not use the daily exchange rate. Instead, they usually use a monthly average. This has two effects:

• Less admin burden on the accountants on finding the daily rates
• Smooths out the effects of noise in the exchange rates

The last point is important because the rules on “prevailing” exchange rates do not really reflect reality. If the posted exchange rate is 1 USD = 1.5 EUR, you can never go to your bank to get that rate. The best you can probably do is something like 1 USD = 1.49 EUR. That remaining 0.01 represents a fee that you’re paying to your bank most likely for the translation, but that amount changes frequently and is based on .

Also, if you are paying EUR from your bank account, the rate you can get from the bank doesn’t really matter because no exchange is actually happening. But there still should be an impact on profit and loss because the market has changed and the value of your assets (may) have changed.

The whole translation to primary currency based on prevailing rates then is a simpler abstraction on top of many complicated transactions in different currencies. Using posted rates then allows accountants to smooth over some of the complexity and ease the admin burden while at the same time largely capturing the impact.

Multi-Currency and Tax

TBD - there is an impact, but the impact depends on the jurisdiction. Tax reporting is separate from accounting reporting and are often quite different. Businesses will generally need to consider both separately and translate their numbers from accounting to tax. Therefore, we can think about this separately and later.

Business Owners

The discussion on accounting standards is all well and good, but how does that impact what the owner wants to see?

This is a topic less of what the rules are and more of judgement on what would be useful for owners. I’m of the opinion that

1. For assets and liabilities, the balance in the original currency matters the most.
2. For revenue and expenses, the balance in the primary currency matters the most.

Let’s say that the business’ primary currency is USD and they routinely transact in EUR and GBP. If they have bank accounts for each currency, I don’t think it matters all that much (for business purposes) what the balance of those accounts is in USD. Instead, the business cares about how many GBP it has in order to meet its obligations. At the same time, if a business owes GBP 10,000 to someone, it doesn’t matter how much that is in USD and how the value changes over time, it matters if the business has GBP 10,000 to repay the loan.

On the other hand, the detail on that the business earned GBP 100,000, EUR 1,000,000 and USD 500,000 in the last year is too much detail. I don’t believe that necessarily aids decision making. Sure, it might be useful is some cases, but often less is more. It’s often more meaningful to translate those various amounts to the primary currency

Financica’s Approach

There’s two levels to this problem. There is the impact of multi-currency on the data capture layer and the effects of multi-currency on the reporting layer. We need to ensure that we’re capturing enough data on transaction recording to aid reporting later on. Let’s discuss the reporting aspect first and then see what data we need to capture.

Reporting

On reporting, we implement three different views on accounting reports (see Key Features):

1. Actual (or “original”, not sure what this should be called): Transactions are reported in their actual currency.
2. Primary: Transactions are reported in the primary currency of the organization
3. Adaptive: Assets and liabilities are recorded in their actual currencies while revenue and expenses are recorded in the organization’s primary currency.

These views should be implemented for balance sheets, income statements and cash flows. The adaptive view is meant to blend the two approaches to display the most meaningful information to the user. The fact that reporting is acting only on summarized information means that these views are reasonably easy to implement on top of the data structures.

	Impact on currencies	Impact of revaluations	Usefulness
Actual	All transactions reported in their original currencies	No revaluations needed	Most accurate data
Primary	All transactions converted to primary currency	Revaluations of all assets/liabilities	Required for accounting and tax purposes
Adaptive	Assets/Liabilities in actual currencies, revenue/expenses in primary	No revaluations needed	Useful for management to aid decision making

A lot of this might be overkill for the consultant user, but getting this right means that 1) our numbers are right and 2) can easily scale for larger businesses.

Data Capture

Each view requires largely the same type of information. With the goal of displaying the accurate amount of a transaction, we need the following pieces of data:

• type of view the user wants (actual, primary, adaptive)
• the amount of the transaction
• The date of the transaction
• the currency of the transaction
• the account type of the particular leg being translated
• the appropriate exchange rate between the currency and the organization’s primary currency, depending on the account type of the leg.

Users might want to enter their own exchange rates. This is something that we should support in the future

Suggestions:

• Exchange rates should be captured upon transaction creation and stored in the Transaction model. This will prevent numerous database calls to get exchange rates. This will also help support users manually entering rates in the future.
• Once the data is stored, it will be a simple calculation to