When a multi-currency EspoCRM setup for sales teams is worth designing up front
A multi-currency setup is worth designing before go-live when a sales team quotes or invoices in more than one currency and leadership needs pipeline and revenue figures that can be compared side by side. Without a deliberate currency configuration, amounts in different currencies sit in the same grids and reports with no common unit, so totals and forecasts become hard to trust. EspoCRM's currency settings give you three levers for this: the Currency List, which defines the currencies your users can select on records; the Default Currency, which is used for filtering, sorting and grid reports; and the Base Currency, which is the currency your exchange rates are specified against. Together they determine which figures can be aggregated and how.
The decision that matters most is who owns the exchange rates. EspoCRM's currency documentation describes a currency rates API and formula-based conversion, but it does not supply market rates on its own. Conversion is only as current as the rates your organization enters or feeds in, so you need to agree the rate source, the update frequency and the person accountable for keeping rates current before the first quote is issued. Ask your finance team whether revenue reporting uses the rate on the quote date, the invoice date or a period-end rate, because that choice changes what the CRM figures mean.
Multi-currency work is worth scoping early if you plan to report on pipelines by region, forecast revenue across markets or connect CRM records to invoicing in another system. Confirm in your own instance, before the build starts, which currencies you need, whether each entity that carries money needs a currency field, and how your Advanced Pack reports and layouts will display converted values. Testing with a small set of real opportunities in each currency will show whether the defaults match what your finance and sales leaders expect.
Which currency settings fit which sales model
This table compares the Currency List, Default Currency, Base Currency, the currency rates API and formula conversion against three common sales models. Read each row to see which setting carries the load for that model and what you must confirm before go-live. The main takeaway is that the base and default currencies control reporting, while rate handling decides whether converted figures stay accurate over time.
| Setting or method | What it controls | Best fit | What to confirm first |
|---|---|---|---|
| Currency List | Which currencies users can select on records and in settings | Teams selling in a few currencies, each with a clear list of allowed codes | Which currency codes your contracts, invoices and price books actually use |
| Default Currency | Currency used for filtering, sorting and grid reports | Single-currency reporting with occasional foreign quotes, where most pipeline stays in the home currency | Whether managers expect totals in the home currency or in the currency of each record |
| Base Currency | The currency against which exchange rates are specified | Reporting in one home currency across many selling currencies, where every rate pairs with the base | How rates are entered, and who owns updating them after go-live |
| Currency rates API | Lets external processes write rates into EspoCRM on a schedule | Teams that need rates refreshed from an external source rather than typed in by hand | Which rate provider you will use, its licence terms, and who maintains the job that calls the API |
| Formula conversion | Converts amounts inside formulas, for use in fields, filters or reports | Custom totals or derived values that need a converted figure beyond the standard reports | Which formulas must convert, and whether converted values need to be stored or calculated on demand |
| Manually maintained rates | Rates entered and changed by administrators inside EspoCRM | Low volume of quotes or a small set of currencies that change rarely | How often rates must be reviewed, and how past figures will be explained if rates change |
How to configure currencies in EspoCRM step by step
This sequence turns a single-currency EspoCRM instance into one that stores, converts and reports amounts in several currencies, with a check after each step so errors surface before sales data depends on them.
Confirm the currencies the business sells in
Before touching settings, the sales operations lead or finance owner lists every currency that appears on quotes, invoices or opportunities, and records which one finance uses for consolidated reporting. Ask whether any currency is used only occasionally, because that choice affects the list you maintain. The step is done when the list is written down and agreed by the people who will read the reports. Check it against a sample of recent deals so no currency in active use is missing.
Set the base currency for exchange rates
An administrator opens Administration, then Currency, and sets the Base Currency, which is the currency every stored rate is expressed against. Choose the currency your rate source publishes against, since rates you enter must match that direction. The check is that the base currency field saves and that the rate entries you create later show it as the reference. Record the choice in your configuration notes, because changing it later means re-entering rates.
Populate the currency list
In the same settings area, the administrator adds each currency from the Currency List that the business uses, and removes any that were defaulted but are not needed. Only currencies on this list appear in currency fields, so a missing entry blocks users from recording a deal in that currency. The check is to open a new opportunity form, select each currency in the dropdown, and confirm that every one is offered and saves without error.
Set the default currency for filters and grid reports
The administrator sets the Default Currency, which EspoCRM uses to filter, sort and total amounts in grid reports. Pick the reporting currency your leadership reads, not the currency of the largest market by habit. The check is that the setting saves and that a list view using currency filters now shows the default currency label in the column headers and totals, which confirms the setting is applied.
Enter or import exchange rates
The administrator enters rates against the base currency, either one at a time in the rate records or through the currency rates API if you maintain them from a finance system. Use a single documented source and a consistent date convention, and record who updates the rates and how often. The check is to compare three entered rates with the figures in the source for the same date and confirm they match exactly. Rates entered without a clear source are the most common cause of later reporting disputes.
Create test records in two currencies
A test user, not a shared admin account, creates at least two opportunities or invoices in different currencies with known amounts, using the same owner and team as real records would have. Write down each amount and the rate you expect EspoCRM to apply. The check is that the saved amounts match the entered values and that the record detail view shows the currency code you selected, which confirms the data is stored correctly before any reporting depends on it.
Test a filtered list and a grid report
Using the test records, the tester applies a filter on the amount field in a list view and then builds a grid report grouped by owner or stage. Compare the converted totals with a manual calculation using the base-currency rates from the previous step. The check is that the filtered list returns the expected records and the grid totals match the expected conversions for a sample of records, within the rounding rules your finance team accepts. Any mismatch should be traced to the rate date, the base currency direction or the default currency before go-live.
How EspoCRM converts amounts in filters and grid reports
The default currency decides how EspoCRM filters, sorts and totals amounts in grid reports, so it is the first setting to get right. According to the EspoCRM currency documentation, the Default Currency is the one used for filtering, sorting and grid report figures, which means a list of opportunities in mixed currencies is compared on a single basis only when this setting is chosen deliberately. Decide with finance which currency leadership reads its numbers in, and confirm with a test record in each currency that the list view and the grid report show the same totals you expect from your own calculation.
The base currency is different. It is the reference currency against which exchange rates are specified in the Currency Rates settings, so every rate you enter must be read in that direction. The documentation supplies the setting names and the role each one plays, but it does not give a worked example of the rate direction or the rounding rules, so the reader should treat both as open questions. Record the rate for one pair in a staging instance, create a sample amount, and check whether the converted figure is the amount multiplied or divided by the rate. Also check how many decimal places appear in the filtered total and the grid total, because a difference of a few cents across hundreds of rows can break a reconciliation.
Formula conversion gives scripts a way to convert amounts when the built-in grid totals are not enough, for example in a before-save script that stores a reporting-currency value on a record. The currency documentation describes this capability at a high level, so confirm the exact function names and argument order against the current Formula documentation for your version before writing any script. Test each script with edge cases such as a zero amount, a currency missing from the list and a rate change between record creation and report run. Only rely on the converted totals in finance reporting after this test passes, and document which rate date and rounding behavior your reports assume.
Security and operational risks in multi-currency rate data
Exchange rates drive every converted total, report and filter in EspoCRM, so who changes them and how they are fed in matters as much as the setup itself. The cards below cover the access, API, history and audit decisions that connect rate data to financial reporting.
Limit who edits currency settings
The Currency List, Default Currency and Base Currency are instance-wide settings, and a change to them affects how every converted amount is read. Restrict edit access to administrators who own finance reporting, and keep those accounts separate from daily sales work. Confirm in your own instance which roles can open the currency settings and rate fields before go-live, since the rights are set through roles rather than a dedicated currency permission.
Decide how rate changes touch history
Updating a rate changes how records are converted when they are next read, so a rate correction can shift previously reported totals in filters and grid reports. Agree a policy before go-live: whether rates are overwritten or added as dated entries, who approves a correction, and whether finance snapshots reports at period close. Test one correction in a non-production copy and compare totals before and after.
Use dedicated API users for rate feeds
If a treasury system or scheduled job pushes rates into EspoCRM, give it its own API user with a role that allows only the currency rate actions it needs. Do not reuse a person's login or an administrator account for the feed. Review the role's permissions after each EspoCRM upgrade, because the feed should not gain access to customer records it does not need.
Authenticate rate calls with HMAC
The REST API supports API key, HMAC and basic authentication. The API documentation describes HMAC as the most secure method and advises against basic authentication, so rate updates should use HMAC signing with the secret held in your secrets manager. Confirm the signing setup against the API docs in a test instance, and keep the secret out of scripts and version control.
Restrict feed access by IP address
A rate feed usually comes from a fixed host, such as a treasury server or integration runner. Use EspoCRM's IP restriction controls to limit where API users can connect from, so a leaked credential cannot be used elsewhere. Confirm the exact allowlist behaviour for API users in your version, because it determines whether the feed still works behind a proxy or NAT.
Trace every rate change
A rate change should be attributable to a user or API user, a time and a value. Confirm how your EspoCRM version records changes to currency rates and whether the stream history is retained long enough for finance audits. If the built-in record is not sufficient, export rate values to a separate log on a schedule and reconcile it against reported totals.
Questions teams ask before setting up multi-currency in EspoCRM
How much effort does a multi-currency setup in EspoCRM take?
The configuration itself is small: you choose the currency list, set a default currency for filtering and reports, and set a base currency that rates are specified against. The effort grows with the decisions around it. Each currency you add needs a rate source, a refresh process and a check that records carry the right currency. Effort also rises when existing data is in one currency and must be reviewed, or when sales reports must match finance's figures. Ask any partner to split their quote into configuration, rate feed integration, data review and testing, so you can see which part drives the cost.
Can an internal admin set up multi-currency without outside help?
Often yes, if the admin has EspoCRM administration experience and the rate source is simple, such as entering rates by hand on a fixed schedule. The EspoCRM currency documentation covers the settings, the currency rates API and formula conversion. Outside help is more useful when rates come from an external feed, when formula conversion must be built into custom fields or reports, or when the team has no one to own the rates after go-live. Your admin should still learn how the default and base currency settings affect filters and grid reports.
What does the work need from finance and sales operations?
Finance should confirm which base currency matches its ledger, which rate source it trusts, and how often rates are refreshed. Sales operations should confirm which currency each product, price list and opportunity uses, and whether reports should show totals in the default currency or in each original currency. Both teams should agree on how historical rates are kept, because a report run next quarter must match one run today. Without these decisions, the technical setup will work but the numbers will not match what finance reports.
How long does multi-currency setup take?
The duration depends mainly on the number of currencies and the source of the rates. A small list of currencies with rates entered manually is a short exercise. A longer list, several rate sources or a rate feed that must be tested against finance's figures takes longer, and so does reviewing existing records in mixed currencies. No duration is given here because none has been researched for this setup. Ask any provider for a timeline tied to your currency list, rate source and number of reports in scope.
Does the EspoCRM license or hosting model change the cost?
The open-source edition is licensed under AGPL-3.0 and can be downloaded and self-hosted for free, according to the EspoCRM pricing page. Your costs are then infrastructure, implementation and support. If you use EspoCRM Cloud instead, the pricing page lists 15 US dollars per user per month on the Basic plan (minimum 3 users), 25 dollars on Enterprise (minimum 5 users) and 69 dollars on Ultimate (minimum 10 users), with the Advanced Pack included in all cloud plans. Grid reports for currency totals are part of the Advanced Pack, so confirm which edition your reports depend on before comparing options.
When is it worth bringing in an implementation partner?
A partner is worth considering when the currency decisions affect revenue reporting, when several rate sources must be reconciled, or when your team lacks the time to test filters and grid reports against finance's numbers. DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope and deliverables agreed in writing before work starts. Ask for a written scope that names the currencies, rate source, reports and test cases included, and what your team must provide.
What should we check after multi-currency goes live?
Check that the default and base currency settings produce the totals finance expects in filters and grid reports, that new records save in the intended currency, and that the rate refresh runs on schedule. Confirm that someone owns the rate updates after handover and that changes to rates or currencies are tested before they reach production. Also confirm the currency rates API is restricted to the accounts that need it, because access to rate data is part of your normal EspoCRM access review.
How DeployOpen scopes and delivers a multi-currency EspoCRM setup
DeployOpen agrees a written, fixed scope before any currency configuration starts. The scope names the currencies your teams sell in, which currency serves as the Default Currency for filtering, sorting and grid reports, which one is the Base Currency used to specify rates, and where each rate comes from. It also records which entities carry money fields that must convert, which filters and grid reports leadership relies on, and who maintains rates after go-live. Because the scope is agreed in writing, you can compare it against your own team's estimate and see exactly what a partner would own. Ask for the deliverables list to name the currency list, the rate entries, the report configurations and the handover documentation.
Configuration and testing happen inside your own infrastructure. DeployOpen sets up the currency list, default and base currencies, and rate entries on your EspoCRM instance, whether it runs on your cloud accounts, data center or air-gapped network. Testing then uses representative records in several currencies, checking that filters, sorting and grid reports show converted amounts the way finance expects. Confirm with your finance lead which rounding and date conventions apply to rates before testing begins, because those choices change totals that people compare against the ledger. Rate values and sources are the client's decision, and DeployOpen does not supply market rate feeds unless they are specified in the scope.
Documentation covers rate maintenance, and retainer support is optional. The handover should describe who updates rates, how often, through which screens or the currency rates API, and how a missed update shows up in reports. Ask for a runbook with a test record set that staff can reuse after a currency is added. If your team wants ongoing help with upgrades, new currencies or report changes, DeployOpen offers retainer support as a separate agreement. Confirm the terms and response expectations in writing, and do not assume they are included in the fixed-scope delivery.
