The Setting You Cannot Un-Click
Zoho CRM’s Multi-Currency setting is a one-way door. Once enabled, every record gets a currency field, every monetary value is interpreted in that currency, and the home currency conversion runs on every report and rollup. Disabling it later requires Zoho support intervention and is, in practice, not done. So before you flip the switch, walk through the seven places it changes how your CRM behaves. None of them are obvious from the documentation.
1. Deal Amount Now Has Two Values
Every deal stores Amount (in the deal’s currency) and Amount_in_Home_Currency (translated using the exchange rate effective when the deal was created, or last manually refreshed). Reports default to home currency. Forecasts default to home currency. List views default to deal currency unless you switch the column. Sales reps quote in deal currency. RevOps reports in home currency. The numbers don’t reconcile unless everyone knows which one they’re looking at.
The fix is a documented column-naming convention. We use Amount (Local) and Amount (USD) everywhere — never just “Amount” — so the reader knows what they’re reading.
2. Exchange Rates Are Snapshots, Not Live
The home-currency amount is calculated when the record is saved using the exchange rate currently in the system. It is not a live conversion. If GBP drops 5% next quarter, your historical deals stay at the old rate unless you manually trigger a recalculation.
This is correct accounting behavior — you don’t want last year’s deals to magically change value — but it surprises people who expect the home currency column to track today’s rate. If you want today’s-rate views, build a Custom Function that takes Amount + Currency and calls a live FX API, then store the result in a custom field. Refresh on demand.
3. Workflow Conditions on Amount Compare Local, Not Home
This is the one that bit a customer hardest. They had a workflow: “When Deal Amount > 50,000, route to Enterprise team.” After turning on Multi-Currency, the comparison ran against the local amount. A deal in JPY for ¥6,500,000 ($46,000) routed to enterprise because JPY 6.5M > 50K. A deal in GBP for £40,000 ($51,000) routed to SMB because GBP 40K < 50K.
The fix is to use the home-currency field in the workflow condition, not the local amount. Same for blueprint state transitions and validation rules. Always test the condition with at least three currencies after migration.
4. Pricebook Pricing Stays Local
Pricebook entries hold prices in the pricebook’s currency, not in deal currency. If you have one pricebook in USD and a deal in GBP, adding a product from the pricebook adds it at the USD price. The deal-level total then converts to GBP using the snapshot rate. Customers see prices that don’t match what’s published on your website.
The two patterns that work: (a) one pricebook per currency, and you pick the pricebook based on deal currency, or (b) build a Deluge function that re-prices line items using a per-currency multiplier at insert time. We default to (a) for catalogs under 200 SKUs and (b) above.
5. Reports Lose Resolution
A pipeline-by-rep report grouped by currency shows separate totals per currency. Aggregate functions like SUM(Amount) are not legal across currencies — Zoho refuses to add 50,000 USD and 6,500,000 JPY. Reports default to summing Amount_in_Home_Currency, which is what you want for executive dashboards but not for rep coaching.
Build two versions of each pipeline report: a “by rep, local” version (no aggregation across currencies, useful for rep conversations) and a “by region, home currency” version (for forecasting). One report doing both jobs poorly is the standard antipattern.
6. Custom Modules Inherit the Cost
Custom modules with monetary fields (renewal value, support contract value, etc.) also get the Currency field and the home-currency twin. Every Deluge script that reads those modules needs to be audited. Code like record.get("Annual_Revenue__c") now returns local; if you wanted home, you need record.get("Annual_Revenue_in_Home_Currency"). Old integrations break silently — the field name they used still exists, but it now means a different thing in mixed-currency orgs.
Search every Deluge function for get("Amount or get("Revenue style patterns and refactor.
7. Integrations Need a Currency Field
Outbound webhooks and integrations that previously sent {"amount": 50000} now need to send {"amount": 50000, "currency": "USD"}. Receiving systems that assumed a single currency need to be updated, or you’ll get downstream reports that conflate currencies. This is a one-month project depending on integration count.
If you have a CFO who reconciles CRM data against NetSuite, plan two weeks of testing on that integration alone before you flip Multi-Currency on.
What to Do Before Flipping the Switch
Run this five-step pre-check:
- Inventory every workflow, blueprint, and validation rule that references a monetary field. Rewrite to use the home-currency version.
- Inventory every report grouped or summed on a monetary field. Decide local vs home for each.
- Inventory every Deluge function that reads a monetary field. Audit and rename.
- Inventory every outbound integration that sends monetary data. Add a currency field to the payload.
- Pick a column naming convention (we recommend
Amount (Local)/Amount (Home)) and apply it across reports.
Then flip the switch. You’ll spend two weeks repairing what you didn’t pre-check. Better to do the work first.
What to Do This Week
If Multi-Currency is already on and you skipped the pre-check, run the audit query: pull every workflow rule and validation rule and check the field names referenced. Anything pointing to the local Amount field instead of home is a routing bug waiting to happen. Quietly fix them.
