Skip to main content
Data Standardization

Currency Normalization: Handling Multiple Currencies in One Dataset

When your dataset contains transactions in USD, EUR, GBP, and JPY, every financial calculation that aggregates across currencies is wrong unless you normalize first. Here's how.

You can normalize multiple currencies in a dataset by standardizing the currency code to ISO 4217 format, converting all amounts to a single base currency using a consistent exchange rate source, and documenting the conversion methodology so future users understand the basis for the normalized values.

Multi-currency datasets are one of the most common sources of silent financial calculation errors. Sum a "revenue" column that contains USD and EUR amounts without converting first, and your total is nonsense — it's a mix of different units presenting as the same unit.

The Two Dimensions of Currency Normalization

Dimension 1: Currency code standardization. Currency codes in real data are often inconsistent: "USD", "US$", "U.S. Dollars", "$", "dollar", and "840" (the ISO 4217 numeric code) might all appear in a "currency" field.

Standardize to ISO 4217 three-letter alphabetic codes: USD, EUR, GBP, JPY, etc. This is the international standard used by financial systems, APIs, and reporting tools.

Dimension 2: Currency amount conversion. For any analysis that aggregates across currencies (total revenue, total spend, average deal size), amounts in different currencies must be converted to a common base currency.

Sohovi profiles your datasets for quality issues in minutes — see what's broken before it breaks your pipeline — try Sohovi free.

The key decisions:

  • Which base currency? (USD is common for global analysis; local currency for regional reporting)
  • Which exchange rate? (Current spot rate, a period average, or the rate at the time of the transaction)
  • Where does the exchange rate come from? (Central bank, financial data provider, fixed internal rate)

Which Exchange Rate to Use

This is the most consequential decision in currency normalization and depends on your use case:

Transaction date rate: Most accurate for financial analysis. Converts each transaction at the rate that applied when it occurred. Requires storing historical exchange rates and joining them to each transaction.

Period average rate: Used in financial reporting (GAAP allows average rates for income statement items). Simpler to calculate but less precise than transaction-date rates.

Current rate: Useful for current snapshots (what is our total ARR in USD today?) but not for historical trend analysis (exchange rate changes will create apparent revenue changes that aren't actually revenue changes).

Sohovi tracks quality trends across runs and alerts you when a metric — null rate, duplicate count, score — moves outside its normal range.

[IMAGE: A financial dataset with transactions in multiple currencies, and the same data after normalization to USD with the base currency and exchange rate source documented]

Documenting Currency Normalization

Always document:

  • The base currency for the normalized column
  • The exchange rate source (ECB, Federal Reserve, internal fixed rate)
  • The exchange rate type (transaction date, period average, current as of [date])
  • Where the original currency and amount are preserved (don't overwrite — add a new column)

Frequently Asked Questions

Q: What is currency normalization in data quality? Currency normalization is the process of standardizing currency codes to ISO 4217 format and converting transaction amounts from multiple currencies into a single base currency — enabling accurate cross-currency aggregation and comparison.

Q: What is ISO 4217 and why should I use it for currency codes? ISO 4217 is the international standard for currency codes — three-letter alphabetic codes (USD, EUR, GBP) and three-digit numeric codes (840 for USD, 978 for EUR). Using ISO 4217 codes ensures your currency field is interpretable by financial APIs, reporting tools, and partners without ambiguity.

Q: Should I convert currencies at the transaction date rate or a current rate? Transaction date rate is the most accurate for historical financial analysis — it reflects the actual economic value at the time of the transaction. Current rates are appropriate for current-state snapshots. Period averages are used for accounting purposes. For analytical work, transaction date rate is preferred.

Q: Where can I get reliable historical exchange rates? The European Central Bank (ECB) publishes daily reference rates for major currencies. The Federal Reserve publishes daily foreign exchange rates. Open-source APIs (Frankfurter, ExchangeRate-API) provide historical rates. Bloomberg and Reuters provide institutional-grade rate data.

Q: Should I overwrite the original currency amounts when normalizing? Never overwrite. Always add a new column for the normalized amount (e.g., "amount_usd") while preserving the original amount and currency code. This preserves the source of truth and allows users to re-normalize to different base currencies or exchange rates in the future.

Q: How do I handle transactions where the original currency is unknown? Flag them explicitly ("currency unknown") rather than assuming a currency. An unidentified currency amount is not valid for any aggregation. Route these records for review and attempt to determine the currency from context before including them in analysis.

Q: What is the impact of using the wrong exchange rate for currency normalization? Using a current exchange rate for historical data creates apparent revenue changes that are actually exchange rate fluctuations. A company's revenue "growth" may reflect a weakening base currency, not actual business growth. This is why transaction-date rates are standard for accurate financial trend analysis.

Q: How do I handle cryptocurrency in currency normalization? Cryptocurrencies are not covered by ISO 4217 (which is for fiat currencies). You can use commonly accepted crypto ticker symbols (BTC, ETH) as a de facto standard, but document this explicitly. Converting crypto to fiat requires the exchange rate at the time of the transaction, and crypto exchange rates have extreme volatility that makes normalization especially sensitive to rate choice.

Q: What's the most common currency normalization mistake? Summing a multi-currency amount column without converting — or converting all values at a single current exchange rate when historical analysis is needed. Both produce numbers that look like meaningful totals but are actually mathematical nonsense mixing different units.

Q: How do I verify that my currency normalization was done correctly? Sample-check the normalized values: pick 10–20 transactions, manually apply the documented exchange rate, and confirm the normalized amount matches. Also check that the distribution of normalized amounts looks reasonable — if you see implausibly large or small normalized amounts for specific currencies, investigate whether the exchange rates were applied correctly.


Multi-currency data that hasn't been normalized produces financial calculations that look precise but are meaningless. Normalize to a common currency, document the methodology, and preserve the originals.

Sohovi Team

Data quality, for people who ship

The Sohovi team writes practical guides on data quality, profiling, and governance to help teams ship better data.

Start for free

Stop guessing. Start knowing your data quality.

Sohovi profiles your datasets in minutes — surfacing completeness gaps, type mismatches, and duplicate patterns before they reach production.

No credit card required · Free forever plan