What the calculator compares
The calculator answers one question: what does the same original amount convert to under two different rates, and how big is the gap? The inputs:
- Original amount and currency. What the employee actually spent, in the currency they spent it — the number on the receipt, before any conversion.
- Settlement currency. The currency the comparison is expressed in: usually the currency the entity reimburses in or keeps its books in.
- Rate A, with its policy moment. The exchange rate at the first moment you are testing — for example, the rate on the transaction date. Rates are entered as units of settlement currency per one unit of the original currency.
- Rate B, with its policy moment. The rate at the second moment — for example, the rate on the reimbursement date.
- Rounding. How many decimal places each converted amount is rounded to before the difference is taken, because the rounding step is itself part of the policy.
The output shows the amount converted at rate A, the amount converted at rate B, and the difference — labeled from the paying entity’s perspective, so you can read directly whether the movement worked for or against the company.
The moments are labeled, not hard-coded: the same comparison works for transaction date versus reimbursement date, submission versus approval, or claim date versus month-end reporting rate. That flexibility is deliberate — the tool is for testing policy assumptions, not only for checking arithmetic on a single claim.
The formula, in the open
Finance users should be able to explain the output without inspecting code, so the calculator displays the formula next to the result:
- Converted at A = original amount × rate A, rounded to the chosen precision
- Converted at B = original amount × rate B, rounded to the chosen precision
- FX difference = converted at B − converted at A
A positive difference means the claim converts to more settlement currency at moment B than at moment A: if the company reimburses at B, it pays out more than the claim was worth at A. A negative difference means the opposite. Whether either constitutes an accounting “gain” or “loss” for your books depends on your accounting treatment — the calculator reports the operational movement and leaves classification to your accountants.
Entering rates the right way around
Rate direction is the most common source of silent error in any FX arithmetic. This calculator expects rates quoted as settlement currency per one unit of the original currency — if the employee spent in currency X and you settle in currency Y, the rate is how many Y one X buys.
Published rates often come the other way. Reference tables are commonly quoted as base currency → foreign currency (how many X one Y buys). If the rate you have is quoted in the opposite direction, invert it — divide 1 by the published rate — before entering it. A quick sanity check catches most mistakes: multiply your original amount by the rate you entered and ask whether the result is plausibly what the receipt is worth in your settlement currency. If a 1,000-unit dinner converts to a house, the rate is upside down.
Consistency matters more than direction convention: both rates must be quoted in the same direction, from the same kind of source, or the difference measures your data rather than the market.
Rounding is part of the policy
On one claim, rounding to 2 versus 4 decimal places moves the result by fractions of a cent. Across hundreds of claims a month, systematically rounding at a different step than your accounting system does produces a steady stream of one-cent reconciliation differences — each trivial, collectively a recurring investigation.
Round in the same place your books do
If the accounting system rounds each converted amount to 2 decimals before summing, the calculator comparison should too. The calculator rounds each converted amount before taking the difference, which matches how most ledgers behave.
Round half away from zero unless your system documents otherwise
And write the convention down. Two systems rounding 0.005 differently disagree forever, one cent at a time.
Keep the unrounded rate
Store the rate at full published precision and round only converted amounts. Rounding the rate itself compounds the error by the size of the amount.
Using the calculator to choose a policy moment
The more valuable use of the tool is prospective: before writing “expenses are converted at the rate on date X” into policy, test what each candidate moment would have done to real claims. The candidate moments differ in what they optimize for:
| Policy moment | What it optimizes | The trade-off |
|---|---|---|
| Transaction date | Fidelity to what the spend was worth when it happened | A rate per receipt date — more lookups, more rates to document |
| Submission date | One rate per claim, fixed while the claim is still the employee’s | Small drift between spend and submission lands on the employee |
| Approval date | Rate matches the moment the company accepted the cost | Approval timing varies by queue, so identical claims can convert differently |
| Reimbursement date | Matches the cash that actually moves | The amount is unknown until payment, so nobody can predict what a claim settles for |
Run a handful of representative claims through two candidate moments at historical rates, and the abstract policy debate becomes a concrete number. Most teams discover the difference is small in calm markets and material in volatile ones — which is the honest basis for choosing where to fix the rate.
For the reimbursement workflow itself, the argument for fixing the rate early is legibility: everyone downstream sees the same converted amount the whole way through. In Clara the FX rate is locked at submission, so the amount that routes the approval is the amount on the claim at payment — the calculator lets you test what that policy, or any alternative, would have meant for your claims. The broader rate-policy design is covered in foreign currency expenses and multi-currency expense management.
Documenting the rate source
A converted amount without a documented source is an assertion. Whatever moment your policy fixes, record where the rate came from, quoted in which direction, retrieved when. Two authority reference points illustrate what sources look like and what they commit you to:
- The European Central Bank publishes euro foreign exchange reference rates, usually updated around 16:00 CET every working day except on TARGET closing days. The ECB states the rates are published for information purposes only and that using them for transaction purposes is strongly discouraged — which is fine for expense conversion documentation, where the rate is a reference standard, not a traded price.
- The U.S. IRS, for translating foreign currency into U.S. dollars for tax purposes, instructs taxpayers to use the exchange rate prevailing when the item is received, paid, or accrued, and — where more than one rate exists — the one that most properly reflects income. It also notes those rates do not apply to paying U.S. taxes to the IRS, where the processing bank’s conversion governs.
The practical rule: pick one source per currency pair, use it consistently, and store the rate and retrieval date with the claim — so the number can be reproduced by someone who was not there.
Reading the result at volume
One claim’s FX difference is arithmetic. A portfolio of them is information:
- Consistently one-signed differences mean the gap between your two policy moments is long enough for rate drift to accumulate — shortening the submission-to-payment cycle shrinks the exposure more reliably than any rate policy.
- Differences concentrated in one currency usually mean one volatile corridor; consider whether that entity’s threshold denominations and reimbursement cadence should differ from the group default.
- Differences that never reconcile to the books usually mean the calculator and the accounting system round at different steps, or one side is using an inverted or stale rate — both findable in minutes with the formula visible.
Export the result as CSV to attach the comparison to a claim, a policy proposal, or a reconciliation ticket. The export is generated in your browser from what you typed; nothing is uploaded.