Ambivo Books User Guide
DocsUG-070
Multi-Currency
Base currency, multi-currency mode, exchange rates, FX gain/loss
Most accounting systems start as single-currency and bolt on multi-currency later. Ambivo Books was designed multi-currency from the beginning: every account, transaction, and ledger entry carries a currency. That said, multi-currency is a feature you opt into per entity, and once on, it brings new mechanics — exchange rates, FX gains and losses, period-end revaluation — that you should understand.
This guide explains the model, the day-to-day workflows, and the roadmap items.
When You Need Multi-Currency
| Situation | Multi-currency needed? |
|---|---|
| US business, all customers in USD, all bills in USD | No |
| US business, occasional foreign vendor (e.g., a contractor in EUR) | Yes |
| Operating bank account in USD plus a foreign-currency bank account | Yes |
| Customers across several countries paying in their local currencies | Yes |
| Reporting financials in multiple currencies | Today: limited — see Roadmap |
If you are unsure, leave multi-currency off. You can enable it later if circumstances change.
The Base Currency
Every entity has one base currency that is set when the entity is created. It is the currency:
- Your reports are presented in
- Your retained earnings and equity accounts live in
- Your tax filings will be in (typically)
The base currency cannot easily be changed after the entity has activity. Pick it carefully at setup time.
Enabling Multi-Currency
- Open Settings
- Find the Currency card
- Toggle Multi-Currency to enabled
Note: As of today the multi-currency toggle on the entity exists but is not strictly enforced — Books will not block you from creating a foreign-currency transaction even if the toggle is off. Enable it explicitly anyway, so it is clear to your team and so the toggle is correct when stricter enforcement is added.
Currencies on Accounts, Transactions, and Ledger
Every key entity has a currency_id:
- Account — Each account is defined in one currency. A USD bank account is a Bank-type account with currency USD; an EUR bank account is a separate Bank-type account with currency EUR.
- Transaction — Each transaction has a currency, set at creation. All line items use the same currency.
- Ledger entry — Each ledger entry carries the currency of the transaction that created it, plus the base-currency equivalent at the time of posting.
This means a single payment from a USD bank account that pays a EUR bill will involve two currencies, and Books captures both sides.
Exchange Rates
When you post a transaction in a non-base currency, Books needs an exchange rate to translate the amount to base currency for reporting.
Where the rate comes from
Today, the rate is captured at transaction time — you enter it on the form, or the system uses a default if available. There is no automatic daily-rate feed today; manage rates manually for each transaction.
Spot vs. average
The captured rate is a spot rate for the transaction date. Books does not currently support averaging or month-end revaluation as a built-in feature — see Roadmap.
A Worked Example: Foreign-Currency Invoice
Your base currency is USD. You invoice a German customer for €1,000 on a day when 1 EUR = 1.10 USD.
At invoice time:
Accounts Receivable (EUR) 1,000 EUR (= 1,100 USD at spot) Sales Revenue (translated) 1,100 USD
The Receivable is recorded in EUR (so you can see your real EUR exposure), but reports translate it to USD for your financial statements.
Customer pays €1,000 a month later, when 1 EUR = 1.15 USD:
Bank (EUR) 1,000 EUR (= 1,150 USD at new spot) Accounts Receivable (EUR) 1,000 EUR (= 1,100 USD at original spot) Realized FX Gain 50 USD
Books recognizes a realized FX gain of 50 USD because the euro strengthened between invoice and payment.
This is the IFRS Phase 1 / "realized FX on assignment" mechanic — currently implemented in Books and applied at the moment of payment-to-invoice assignment.
Realized vs. Unrealized FX
- Realized FX gain/loss — Recognized when a foreign-currency item settles (a payment hits, an invoice clears). Books implements this today.
- Unrealized FX gain/loss — Recognized at period-end on still-open foreign-currency balances (an unpaid EUR invoice as of Dec 31). Books does not yet implement period-end revaluation — see Roadmap.
For most small businesses the realized side is the important one; unrealized matters for IFRS-compliant statements at period-end.
Multi-Currency Bank Accounts
A bank account holds money in one currency. To handle multiple currencies you create multiple bank accounts:
- Chase USD Operating (Bank-type, currency USD)
- Wise EUR Balance (Bank-type, currency EUR)
- Wise GBP Balance (Bank-type, currency GBP)
Each connects (or imports) independently. Reports show each in its own currency and roll them up to base for the Balance Sheet.
Wise and Multi-Currency
Wise is the practical answer to multi-currency payouts. Through the Wise integration, you can:
- Hold balances in many currencies
- Pay vendors in their local currency from your local-currency funding
- Capture the actual rate Wise used (visible on the transfer detail)
- Reconcile each currency balance separately
See Transfers Sent (Wise Payouts) (UG-023).
Reports in Multi-Currency
Reports are produced in the entity's base currency. Every transaction is translated using the rate captured at posting time.
If you have a EUR-denominated bank account, its balance shows in USD on the Balance Sheet (translated at the historical rates of the transactions in it). The "translated" balance can drift from the "actual" EUR balance × current rate — that drift is the unrealized FX gain or loss, which Books does not yet revalue automatically.
For now, if you need a EUR-based view, run a per-account statement on the EUR account and read the EUR column.
Roadmap (Phase 2 and Beyond)
The multi-currency model has more on the way:
- Period-end revaluation — Re-translate open foreign-currency balances at period-end and post the unrealized FX gain/loss. See docs/ifrs_phase2_period_end_revaluation.md in the codebase for the design.
- Exchange rate table with historical rates — Centralized rates so you don't enter them per-transaction.
- Daily rate feed — Automatic rate updates from a market data provider.
- Native foreign-currency reports — Run an Income Statement in EUR even when the base currency is USD.
If you have a strong need for any of these, talk to your account manager — priority is partly customer-driven.
Common Questions
Can I have a foreign-currency Chart of Accounts?
You can have foreign-currency accounts — for example, a EUR bank account. The chart of accounts itself is one list spanning all currencies; each account has its own currency.
What rate is used when I post a foreign-currency transaction?
The rate you enter on the transaction. Books does not yet pull live rates. Use a daily reference rate (your bank's rate, or a public source like xe.com).
My Income Statement shows revenue from a EUR invoice — what currency is it in?
Translated to your base currency at the rate captured when the invoice was posted.
Why does my bank balance in Books not match the bank's EUR balance × today's rate?
Because Books translates each transaction at its historical rate, not today's rate. That difference is unrealized FX, which is recognized at revaluation (currently roadmap).
Can I record an invoice in one currency and accept payment in another?
Yes — Books handles cross-currency assignment and recognizes realized FX gain/loss at the moment of clearing.
Can the base currency be changed after entity creation?
Practically, no. There is no automated re-translation. The right path is to create a new entity in the new base currency.
Should I bother enabling multi-currency if I only have one foreign vendor?
Yes — even one foreign vendor justifies it. Without multi-currency, you would have to pay them in your base currency and lose visibility of the FX delta.
Tips and Best Practices
- Pick the right base currency at entity setup. It is the most consequential setting in multi-currency.
- Create separate bank accounts for each currency rather than running mixed-currency activity through one account.
- Capture rates carefully. A rate typo today is a reconciliation headache forever.
- Don't assume a flat rate per month. For materially-sized transactions, use the actual day's rate; for tiny transactions, a monthly average is fine.
- At period-end, list every open foreign-currency balance so you (or your CPA) can post a manual revaluation entry until automatic revaluation ships.
- Use Wise for the payment side. It handles the FX cleanly and captures a defensible rate.