How we picked four rate sources for Zenrate — and why one isn't enough

The first expense report I tried to file from Bangkok back to a Japanese corporate client got rejected within an hour. The receipt was fine. The amounts were fine. The problem was the rate column: I had used a free online converter showing 0.2418 baht per yen on the transaction date, and the accountant's policy required the Mizuho TTM rate, which had closed that day at 0.2401. Seventeen ten-thousandths of a baht per yen. On a 28,000-baht hotel folio, that was a 0.7% gap. On the trip total it came to a few hundred yen. The accountant didn't care that my rate was closer to the actual market mid; she cared that it didn't match the rate she was required to use. So I re-did every line of the report against Mizuho TTM and resubmitted.

That experience seeded the design of Zenrate's rate-source system, and it's the reason we don't ship a single "the" exchange rate. There is no such thing.

What "the rate" actually means in accounting

For day-to-day questions — what does this coffee cost in dollars, how much yen do I need for the train — almost any rate source is fine. The market mid you see on Google or XE is within a fraction of a percent of every other source for major pairs. If you're off by 0.3%, the consequence is that you slightly over- or under-tip.

For accounting it's different. The rate is not just a translation — it's a citation. Your books say "this transaction in foreign currency translated to this amount of home currency at this rate from this source on this date." An auditor's job is to verify, years later, that the citation is correct. If your books say "0.2418 from XE" and your company's policy says "Mizuho TTM," the citation is wrong even if the number is close.

Different jurisdictions and different corporate policies require different sources. In Japan, most SMEs use the TTM rate from one of the three megabanks (MUFG, Mizuho, SMBC). In the Eurozone, ECB's daily reference rate is the convention. In the US, federal reporting uses Treasury's quarterly rates. In the UK, HMRC publishes a monthly average that small businesses use for VAT returns.

These are not interchangeable. ECB's rate is the right answer for a German freelancer translating an invoice to euros and the wrong answer for a Tokyo SME translating the same invoice to yen. There is no abstract "fair" rate that satisfies both.

The four sources we selected

When I was designing Zenrate I made a short list of what an accounting-grade source needed to be: officially published by a recognized authority, fetchable on a per-date basis going back several years, and known by name to the accountants who would be reading the resulting reports. That eliminated commercial aggregators (no auditor accepts "the XE rate" as a primary source) and most central banks of small economies (publication formats too irregular).

The list converged on four:

European Central Bank publishes a daily euro reference rate at around 14:15 Central European Time on TARGET2 business days, against roughly thirty other currencies. The Frankfurter API mirrors ECB's data cleanly and lets us query any past date in one HTTP call. ECB is the default for EU users and, in practice, the source we fall back to whenever a more specific source isn't available — its coverage is broad and the data is trustworthy.

Mizuho Bank publishes daily TTM (Telegraphic Transfer Middle), TTS (sell), and TTB (buy) rates for the major currencies plus a handful of regional pairs. The CSV format is reliable and we ingest it into a database, so most lookups for recent dates are served from cache without a fresh fetch. We chose Mizuho over MUFG and SMBC purely for technical reasons: Mizuho's published format was the most reliably parseable when we surveyed the three in early 2026. The numbers are within a few hundredths of a yen of MUFG and SMBC for the same pair on the same day, so for accounting purposes the three are interchangeable; you should match whichever your company's policy specifies, and we'll add MUFG and SMBC as alternative sources when there's enough demand.

U.S. Treasury publishes a Foreign Currency Reporting Rates file used by U.S. federal agencies. It's quarterly with mid-quarter amendments when a currency moves more than ten percent. The granularity is coarse — one rate per quarter is too low-resolution for most travel expense work — but it's the official rate for U.S. federal reporting and for some U.S.-based enterprise accounting policies that have standardized on it. The Treasury fetcher hits `api.fiscaldata.treasury.gov` and returns the latest available rate on or before the requested date.

HMRC monthly average is the rate UK businesses are entitled to use for VAT periods. It is published monthly and is intended to smooth out daily volatility for businesses that don't want to track per-transaction rates. As of the current codebase, HMRC is documented in our rate-source registry as a type identifier but is not yet implemented as an active fetcher; UK users today receive an ECB cross-rate fallback. Building the HMRC fetcher is on the near-term roadmap; until it ships, the citation in receipts that should be HMRC reads "ECB" so the audit trail is accurate about what data was actually used.

Why a single global source doesn't work

The objection I'd expect — and have heard from people coming from generic FX tools — is that this is over-engineering. Why not just pick one source, average across the day, and call that "the rate"?

Because no auditor will accept it. Auditing exchange rates is not about the abstract correctness of a number; it's about whether the number cited is the one your company's stated policy required. If your policy says "TTM from a major Japanese bank," then the only acceptable rates are TTM from a major Japanese bank. A synthetic "global average" satisfies the precision criterion (it's probably within 0.1% of TTM on any given day) but fails the citation criterion (it's not from a recognized source).

This was the most counterintuitive thing for me to internalize when I started talking to accountants seriously. As a software engineer I wanted to optimize for accuracy. They wanted to optimize for defensibility, which is a different problem.

The other reason single-source doesn't work is that the same multinational employee can file two expense reports in a year against two different policies. A Japan-based employee on a US business trip filing through a US-domiciled travel system has to use whatever rate that system requires (often U.S. Treasury or a daily commercial source). The same employee filing a parallel Japanese expense report for tax purposes uses Mizuho TTM. Both reports are correct for their respective jurisdictions and both should produce defensible numbers from Zenrate, with the source clearly cited.

Cross-rating, and the small loss it introduces

For currency pairs that a source doesn't publish directly, we cross-rate through USD (for Mizuho and U.S. Treasury) or EUR (for ECB). For Chinese yuan to Japanese yen — a pair Mizuho doesn't publish direct most days — we fetch Mizuho's USD/JPY and Mizuho's USD/CNY for the requested date, then compute the cross.

This introduces a small rounding loss. Mizuho publishes rates to four decimal places for most currencies. A cross constructed from two such values has a maximum rounding error of roughly half a basis point — meaningless for accounting purposes, but mathematically present. If a Chinese counterparty independently quoted a direct CNY/JPY rate from a Chinese bank, the two numbers might differ by 1–2 hundredths of a percent. Neither is wrong; they're both correct citations of their respective methodologies.

We document this in the per-pair pages so users aren't surprised when reconciliation against an outside source shows a tiny gap.

What we considered and rejected

Commercial aggregators like Open Exchange Rates or Fixer. The data is fine but auditors don't recognize the source names. A receipt citing "the Open Exchange Rates rate" is not defensible against a policy that requires Mizuho TTM. We use a commercial aggregator (`exchangerate-api.com`) for the live converter widget on the homepage and on /[pair] pages — where the use case is "what does this cost right now" — but we don't write commercial-aggregator citations into receipt records.

Every individual central bank. Tempting because the data is authoritative, but the maintenance cost is high. Each central bank publishes in a different format, has a different update cadence, observes different holidays, and ends up needing its own fetcher. We started with the four sources whose users we know we have today; we'll add more (Reserve Bank of Australia, Bank of Korea, People's Bank of China) when there are enough users in those jurisdictions to justify the integration work.

Crypto rates. Different problem entirely. Different volatility, different sources, different audit conventions (or lack thereof). We had crypto in the product through 2024, removed it in 2025, and the product is better focused without it.

How users pick

In Zenrate's settings, the rate source is a one-time choice with sensible defaults based on the user's country: Japan defaults to Mizuho, EU defaults to ECB, US to Treasury, UK to HMRC (currently with the ECB fallback noted above). Users can override the default at any time. Mid-year changes are allowed but flagged in the UI as something to document in the company's accounting policy notes — switching sources halfway through a fiscal year is the kind of thing auditors notice.

The setting applies to all new entries from the moment it changes. Historical entries keep the source that was active when they were recorded; we don't retroactively re-translate, because that would silently change historical book values.

Why this matters for Zenrate

The four-source system exists because the "correct" exchange rate is whatever your company's policy says it is — and that policy is jurisdictional, not technical. Every Zenrate receipt record stores not just the rate but the source name and the policy in effect at the time of entry. When an auditor asks "where did this number come from," the answer is on the page: the source, the policy, the date the rate was looked up, and the rate itself. That citation is the point of the design, not the underlying math.

— Koryu, Endots LLC