A foreign currency expense is any cost an employee incurs in a currency other than the one the entity reports in. The mechanics look trivial — multiply by a rate — and then produce more month-end questions than almost anything else in the expense process.
The reason is that a single claim carries three different dates and at least two defensible rates, and nothing in the receipt tells you which combination applies. Get the combination right and the expense is a two-minute posting. Get it inconsistent across claims and you inherit a reconciliation with no owner.
This guide covers what actually has to be decided per claim, how to pick a rate source you can defend to an auditor, where the difference between two rates is supposed to end up, and the edge cases that break otherwise-sound policies.
The test is the entity's functional currency, not the employee's location. An employee based in Mexico submitting in Mexican pesos to a Mexican entity is a domestic expense. The same employee submitting in pesos to a US-reporting entity is a foreign currency expense, and so is a US-based employee submitting a euro hotel bill.
Three variants come up constantly and are treated differently:
Only the first two involve a real currency conversion someone paid for. Conflating them with the third is the origin of a surprising number of disputes about whether an employee was "made whole."
Every foreign currency claim carries three dates, and a policy has to say what each one does.
Transaction date. When the cost was incurred. IAS 21 requires a foreign currency transaction to be recorded in the functional currency by applying the spot exchange rate at the date of the transaction, so this is normally the accounting anchor.
Submission or approval date. When the workflow fixed a value. This is the number the employee is told and the approver signs off on. It has no accounting significance by itself — it acquires significance only because a policy assigns it one.
Settlement date. When the money moved. Any movement between the recorded rate and this one is a real difference that has to land somewhere.
The failure mode is not choosing the wrong date. It is using different dates for different claims without deciding to. A trip expensed the same week and a trip expensed six weeks later go through the same policy and come out with materially different treatment, and nobody can point at the rule that made them differ.
Write the mapping down once: record at the transaction-date rate; reimburse at the rate fixed on submission; recognise the difference at settlement. Three sentences remove most of the recurring questions.
What matters is that the source is documented and applied the same way to every claim. The published guidance sets out which rate applies; it does not bless a shortcut for picking one.
The IRS states the general rule as using the exchange rate prevailing when you receive, pay or accrue the item, and where more than one rate exists, the one that most properly reflects your income; its guidance also lists sources it points taxpayers to. HMRC takes the opposite approach for customs valuation and publishes a rate itself: a monthly rate that is valid for the calendar month, reviewed weekly, and updated the following week if commercial rates diverge from it by more than 5%.
Those two together describe the realistic options:
| Source type | Example | Good for | Watch out for |
|---|---|---|---|
| Published authority rate | HMRC monthly customs rate | Customs and VAT; stable, defensible, easy to audit | Fixed for a period, so it will not match what anyone actually paid |
| Central bank reference rate | ECB daily euro reference rates | A neutral benchmark for policy or for checking outliers | The ECB publishes these for information only and strongly discourages using them for transaction purposes |
| Market data provider | A commercial FX feed | Matching real market levels at a timestamp | You must be able to reproduce the rate later; store the value, not the lookup |
| The employee's own statement | Their card issuer's rate | Reimbursing exactly what they were charged | Includes an issuer spread; differs per employee for the same expense |
Whichever you choose, two rules make the choice hold up. Record the rate as a value on the claim, not as a formula pointing at a rate table — the table will have moved by the time anyone asks. And record the source and the date it was taken, because "1.0842" without provenance is not evidence.
Two claims, same hotel, same amount, different weeks — and the totals differ. That difference is not an error, and treating it as one is the mistake.
Paragraph 21 of IAS 21 requires a foreign currency transaction to be recorded, on initial recognition in the functional currency, at the spot exchange rate at the date of the transaction, and paragraph 22 defines that date as the one on which the transaction first qualifies for recognition. A reimbursement that is approved but not yet paid stays outstanding after that date, which is what brings ordinary expense claims into scope of the question.
In practice that produces two kinds of difference:
Neither is a reason to change the expense. The expense was what it was, at the rate on the transaction date. The currency movement is a separate event with its own line, and keeping the two apart is what stops a rate change from silently rewriting the cost of a business trip taken two months ago. We are preparing an FX gain/loss calculator that works this arithmetic through on a single claim, for readers who would rather see the numbers than the rule.
An employee of a US-reporting entity pays a €1,000 hotel bill on 3 March. They submit it on 24 March. Finance pays it on 8 April.
| Step | Date | Rate applied | Amount | What it is |
|---|---|---|---|---|
| Expense incurred | 3 Mar | 1.08 USD/EUR | USD 1,080 | Recorded cost, per IAS 21 spot rate at the transaction date |
| Claim submitted and fixed | 24 Mar | 1.09 USD/EUR | USD 1,090 | The amount promised to the employee under policy |
| Period end, still unpaid | 31 Mar | 1.10 USD/EUR | USD 1,100 | Liability retranslated; USD 20 unrealised difference on the recorded amount |
| Paid | 8 Apr | 1.11 USD/EUR | USD 1,110 | Settlement; the remaining difference realised |
The employee receives USD 1,090 — the amount they were told at submission. The cost of the trip in the books stays at USD 1,080. The USD 30 that separates them is a currency movement, split across two periods, and it is visible as such rather than buried inside the travel line.
Change the policy — reimburse at the settlement rate instead — and the employee receives USD 1,110, the travel cost is still USD 1,080, and the difference is the same USD 30 arriving in one piece. Either is defensible. What is not defensible is doing the first for some claims and the second for others.
An auditor reviewing a foreign currency expense is reconstructing a decision. These are the fields that let them do it without an interview:
| Field | Why it is asked for |
|---|---|
| Original amount and ISO 4217 currency code | The claim as it exists on the receipt, before anyone's arithmetic |
| Transaction date | Establishes which spot rate should have applied |
| Rate value, source and date taken | The three together are the evidence; any one alone is not |
| Converted amount and which decision it governs | Distinguishes the recorded cost from the promised reimbursement |
| Approver and timestamp | Who accepted the converted value |
| Entity and functional currency | Determines whether this is a foreign currency expense at all |
| Settlement date and settled amount | Closes the loop and locates the realised difference |
| The receipt itself, in its original currency | The only primary document in the set |
Note the last row. A converted amount with no original-currency document is a derived number with nothing behind it, and it is the single most common gap in otherwise well-run expense files. See expense audit trails for how long each of these needs to survive.
The card spread. The employee's issuer applied its own rate plus a margin. Reimbursing at a market rate leaves them short by the spread; reimbursing at their statement rate means the same expense costs the company different amounts depending on who paid. Most policies pick one and say so; the ones that generate tickets are the ones that never decided.
Refunds and partial credits. A cancelled booking refunded three weeks later comes back at a different rate. The refund is a separate transaction at its own date — netting it against the original claim at the original rate produces a number that matches neither.
Prepaid and multi-leg travel. A flight bought in one currency for a trip in another has a transaction date well before the travel date. The transaction date governs; the trip date is not a rate date.
Per diems and allowances. These are set in a currency by policy, not incurred in one. They convert at whatever the policy says and have no underlying receipt, which means the policy document itself is the evidence. Keep the version of the policy that was in force.
Restricted or thinly traded currencies. When a currency is not readily exchangeable, a single published rate may not represent an obtainable one. This is a real accounting question with its own guidance and it is well past the point where a general guide should be prescriptive — get advice for the specific currency and period.
The employee submits in the currency they spent in. There is no conversion step for them to perform and therefore none for them to get wrong, and the original amount and currency are what land on the record.
The rate applied is the one published for the transaction date on the receipt, fetched automatically from a market feed, and it is locked onto the claim the moment the employee submits. That fixes the rate at a known date, from a known source, so the value the employee is told, the value the approver accepts and the value on the reimbursement record are the same number rather than three recalculations of it.
Where the feed publishes no rate for that currency and that date, the claim is still submitted and still reaches the payment report — in its own currency, for its own amount, with the FX column blank — and finance applies the bank's rate when it executes the transfer. Nothing back-fills the conversion afterwards, so the rate that ends up in the books for those claims is the one the bank gave, documented at execution rather than at submission.
For finance, the output is a payment-ready report: expenses grouped by currency and by the bank account each needs to be paid from, with the FX breakdown included. Clara does not execute the transfers — the report is built for a finance team to act on through the banking platform they already use.
What this does not do is decide your accounting policy. Which rate anchors the recorded cost, how the realised and unrealised differences are presented, and what your auditors expect to see are decisions that stay with your finance team. The workflow's job is to make sure the evidence for those decisions exists on the claim rather than in someone's inbox.
The worked example uses illustrative exchange rates chosen to show the mechanics. They are not quoted rates for any date and should not be used as figures.
The sources below are accounting standard setters, tax authorities and central banks. They set out general requirements; the treatment that applies to a particular expense depends on the entity's functional currency, the accounting framework it reports under, and every jurisdiction involved.
For the accounting record, the spot rate at the transaction date is the standard answer: IAS 21 requires a foreign currency transaction to be recorded in the functional currency using the exchange rate at the date of the transaction. For reimbursing the employee, the rate is a policy choice — most teams fix it at submission so the amount promised matches the amount paid.
For tax, the answer is jurisdiction-specific but converges on the same idea. The IRS points to the rate prevailing when the item is received, paid or accrued, and where several rates exist, the one that most properly reflects income. HMRC publishes its own monthly rate for customs valuation, valid for the calendar month and revised weekly if commercial rates diverge by more than 5%. The practical takeaway is that consistency is doing more work than the specific choice: pick a documented source, apply it the same way to every claim, and record the rate value on the claim rather than a pointer to a table.
An unrealised difference arises when a foreign-currency balance is still outstanding at a reporting date; a realised difference arises when it is actually settled. An approved-but-unpaid employee reimbursement is normally treated as a monetary liability, and how it is retranslated at period end — and where the resulting difference lands — depends on the accounting framework your entity reports under. Confirm the treatment with your auditor rather than assuming it.
When the reimbursement is subsequently paid, the difference between the amount carried and the amount actually settled is realised. Neither event changes the recorded cost of the underlying expense, which stays at the transaction-date rate. Keeping the two separate is what prevents a currency movement from retroactively rewriting the cost of a trip that already happened, and it is why finance teams generally resist the intuitive-sounding idea of "just updating the expense."
Yes. The converted amount is a derived figure; the receipt in its original currency is the only primary document in the file. Without it, there is nothing to check the conversion against, and the whole record reduces to an assertion about a number.
This is the most common gap in otherwise well-organised expense files, usually because a system stored the converted value and treated the attachment as optional. The rule that avoids it is to require the original-currency document at submission and to keep the original amount and its ISO 4217 currency code as first-class fields on the claim, not as text inside a description. Retention should follow the longest applicable requirement across the jurisdictions the entity operates in, since the document and the rate record have to survive together to be useful.
Decide, write it down, and apply it to everyone. There are two defensible policies. Reimburse at a documented market or published rate, and the employee absorbs their issuer's spread — simple to administer, and occasionally leaves someone a few units short. Or reimburse at the rate on the employee's own statement, and the company absorbs it — fairer per person, but the same expense then costs the company different amounts depending on who paid it and which card they used.
What causes the recurring support tickets is having neither policy. An employee compares the reimbursement against their statement, finds a discrepancy of a few percent, and nobody can say whether it is expected. Stating the rule in the policy — and, if you choose the market-rate option, saying plainly that issuer spreads are not reimbursed — converts a dispute into a documented answer.
Treat the refund as its own transaction on its own date, at the rate applicable then, rather than reversing the original claim at the original rate. A booking cancelled and refunded weeks later returns a foreign-currency amount whose value in the reporting currency has moved, and forcing it back through the original rate produces a figure that matches neither the original expense nor the money that actually came back.
The residual difference is a currency movement and belongs with the other exchange differences, not inside the travel cost. In practice the cleanest handling is to record the refund as a separate line linked to the original claim, so the pair is still legible to anyone reviewing the file later, while each carries the rate that genuinely applied to it.
Yes, and it is the first thing to establish. Whether an expense is a foreign currency expense at all is determined by the functional currency of the entity that carries the cost, not by where the employee lives or which currency they used. The same peso expense is domestic to a Mexican entity and foreign to a US-reporting one.
This matters most when a group operates several entities. An employee whose costs sit with one entity but who is administratively attached to another can have their claims translated under the wrong functional currency, which is a difficult error to spot because every individual number looks reasonable. Making entity ownership an explicit field on the claim, decided at submission rather than corrected at close, is what prevents it.
This guide covers how a single foreign-currency expense is recorded, reimbursed and evidenced. It draws on accounting standards and tax-authority guidance, which describe general requirements rather than the treatment for any one company.
Manage your team's expenses in any country and currency. Receipts, approvals, and bank-ready payment reports — all in one place.