Understanding Multi-Currency
If your business only ever deals in one currency, you can skim this section — REDA just works, and there's nothing to switch on. But the moment you have companies in different countries, or you sell to customers who pay in another currency, you enter the world of multi-currency accounting. This article explains, from the ground up, what that means, the few new ideas you'll need, and how REDA handles it — so the rest of this section makes sense.
Access you'll need. Any REDA Financials permission set can work in a multi-currency org; turning multi-currency on and configuring entity currencies requires the Accounting Admin v2 (or Accounting Controller v2) permission set, coordinated with your Salesforce administrator.
The key idea: a company's "home" currency
Every company keeps its books in one main currency — the currency of the place it operates and reports in. Accountants call this the functional currency. A UK company's functional currency is the pound; a US company's is the dollar. No matter what currency a particular sale happens in, that company's accounts, profit and balance sheet are all expressed in its one functional currency.
REDA's two modes
REDA runs in one of two modes. It ships in single-currency mode; your administrator switches it to multi-currency with one org-wide setting (Multi Currency Enabled, in the Financial Admin Console) once the Salesforce platform's own currency management is on. The differences at a glance:
| Single-currency | Multi-currency | |
|---|---|---|
| Company currency | Every company uses the one org currency — REDA blocks saving an entity in any other ("In single-currency mode, Currency Code must match the org default currency.") | Each company has its own home currency |
| Exchange rates | Not needed | Maintained as dated rates (in Salesforce's standard rate table) |
| Currency choice on documents | None — there's nothing to choose | A Currency picker lets a document be raised in any active currency |
| Exchange gains/losses | Don't arise | Recorded automatically |
| Right for | A single-country business | Multi-country groups (like our Meridian example) |
Do you need multi-currency?
| If you… | Then… |
|---|---|
| Operate one company, in one country, in one currency | Stay single-currency. Simpler, nothing to maintain. |
| Have companies in different countries / currencies | You need multi-currency — each company keeps its own home currency. |
| Are one company but sometimes invoice customers in a foreign currency | You need multi-currency — so those documents can be raised and converted. |
| Report a group across currencies | You need multi-currency — for the translation into one group currency. |
What multi-currency gives you
- A home currency per company — Meridian Properties UK Ltd keeps books in GBP, Meridian Properties US LLC in USD, the India company in INR, the Brazil company in BRL.
- Foreign-currency documents — the UK company can bill a customer in EUR; REDA converts it to GBP for the books.
- Dated exchange rates — each document converts at the rate that applied on its date, not today's rate.
- Automatic exchange gains and losses — when rates move between invoicing and payment, REDA records the difference (to international-standard treatment, IAS 21).
- Group reporting in one currency — every posted entry also carries a value in the group's corporate currency, so combined reports can show all companies on one scale.
One sale, seen through multi-currency
Here's the whole idea in a single transaction. Meridian Properties UK Ltd (home currency GBP) bills a European customer €10,000. What happens, in order:
The document is raised in euros
The Currency picker on the invoice is set to EUR. The customer sees €10,000 — the amount they actually agreed to pay.
Posting converts it to the company's home currency
REDA looks up the exchange rate in force on the invoice date, stamps that rate on the document, and records the sale in the UK company's books in GBP. The books are always kept in the home currency; the euro figure is preserved alongside.
Payment may arrive at a different rate
If the euro has moved by the time the customer pays, the same €10,000 is worth a slightly different number of pounds. That difference is a real exchange gain or loss, and REDA posts it to the entity's FX accounts automatically.
Every posted entry in a multi-currency org actually carries the amount at three levels at once — the document currency (EUR), the company's home currency (GBP), and the group's corporate currency — which is what makes reports at any altitude come out right. That model has its own article: 3-Tier Currency Architecture.
Where to go next
- Enabling Multi-Currency — switch it on at both levels.
- 3-Tier Currency Architecture — the three currencies REDA tracks.
- Exchange Rates — the rates that drive conversion.
- Currency on Documents — how currency reaches each document.
Frequently asked questions
No — and it shouldn't. A company has exactly one home (functional) currency. It can transact in others, but everything is recorded in its single home currency. Two home currencies would mean two companies.
Yes, to raise those euro invoices and convert them. Your home currency stays GBP; multi-currency just lets the odd foreign-currency document be handled properly, with the exchange difference recorded when it's paid.
It's a deliberate, one-time setup (and at the Salesforce level, permanent), so it's best decided early. See Enabling Multi-Currency for the exact sequence and cautions.
You choose. Financial reports offer a currency view of Entity Functional (one company, in its own home currency) or Corporate Currency (everything translated to the group currency). When a report spans entities with different home currencies, REDA shows it in the corporate currency and tells you so.
No. Existing entries simply have all their currency levels equal (with a rate of 1), because document, home and corporate currency were all the same. New documents gain the ability to differ.
Was this article helpful?