What counts as a foreign currency expense
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:
- The employee paid in a foreign currency with their own card. The employee bore a conversion; the entity bears another. The two will not match.
- The employee paid in a foreign currency with a company card. The conversion happened once, on the card statement, and there is a settlement amount to reconcile against.
- The employee paid in their local currency, but the entity reports in another. No conversion happened at the point of sale; the conversion is purely an accounting translation.
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."
The three dates on one expense
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.
Picking a rate source you can defend
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.
Where the difference goes
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:
- Unrealised. The claim is approved but not yet paid at period end. The liability is retranslated; the difference is recognised even though no money has moved.
- Realised. The claim is paid. The difference between the amount recorded and the amount actually settled is recognised at that point.
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.
A worked example
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.
The documentation pack for one claim
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.
Edge cases that break good policies
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.
How Clara handles foreign currency expenses
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 exchange rate is locked at the moment the employee submits. That fixes the second of the three dates above at a known point, 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.
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.