The finance problem starts after the transaction
The transaction itself is usually the easy part. An employee pays a hotel bill in a foreign currency, keeps the receipt, and submits a claim. From that moment the expense has to survive four separate handoffs, and each one can change the number.
Submission fixes an amount and, implicitly or explicitly, a rate. Approval accepts that amount — or bounces it back, at which point the rate may need to be refixed. Reimbursement pays a value that may differ from the approved one if time has passed. Accounting records the expense in the entity's functional currency, on a date that may be none of the above.
When the process is manual, each handoff introduces a chance for the rate to be recalculated by a different person, from a different source, on a different day. The resulting record is not wrong so much as unexplainable: the numbers no longer tell you which decision produced them.
The cost shows up in three places. Employees chase reimbursements that do not match what they spent. Finance reconciles differences that have no owner. Auditors ask for a rate source and receive a screenshot.
The four rates hiding in one foreign-currency expense
Most disagreements about foreign-currency expenses are really disagreements about which of four rates someone means.
The rate the employee got. What their card issuer or bank actually applied, including any spread. It is on their statement and nowhere else, and it is the number they will compare their reimbursement against.
The rate at the transaction date. The market rate on the day the expense was incurred. IAS 21 requires a foreign currency transaction to be recorded in the functional currency at the spot rate at the date of the transaction, so this is usually the accounting anchor.
The rate at submission or approval. The rate the workflow applied when it fixed the claim value. This is the one the employee is told they will be paid, and the one the approver signed off on.
The rate at payment. The rate on the day the money actually moved. Between approval and payment, this drifts — and the difference is a real gain or loss that lands somewhere in the books.
None of these is the "right" one in the abstract. Each answers a different question, and a workflow that silently mixes them produces reconciliation work that looks like an error but is really an undocumented policy. The fix is not picking a single rate for everything; it is deciding which rate governs which decision, and recording that choice on the expense.
Which exchange rate should you use? Three answers, three audiences
The reason this question keeps coming back is that tax authorities, accounting standards and employees are each asking something different.
| Audience | What they need | Typical rule |
|---|---|---|
| Accounting | A consistent basis for recording and retranslating | IAS 21 (paragraph 21): the spot exchange rate at the date of the transaction, applied on initial recognition in the functional currency |
| Tax (US) | A rate that properly reflects income | IRS guidance: the rate prevailing when you receive, pay or accrue the item; where several rates exist, the one that most properly reflects income |
| Customs / VAT (UK) | A stable, published rate for a defined period | HMRC publishes a monthly customs rate valid for the calendar month, reviewed weekly and updated if commercial rates diverge by more than 5% |
| The employee | To be made whole for what they actually spent | Company policy — usually the rate at submission, so the amount they are told is the amount they receive |
A single company can legitimately need all four at once. What causes trouble is not the plurality; it is leaving the choice implicit. A policy that says "we reimburse at the rate on the submission date, using [named source], and book at the transaction-date rate per IAS 21" answers every one of those audiences in a sentence, and turns an argument into a lookup.
What a multi-currency expense workflow must capture
Whatever rate policy you land on, the record has to carry enough to reconstruct the decision without asking anyone. At minimum:
- Original amount and original currency, exactly as they appear on the receipt.
- Transaction date, distinct from the submission date.
- Rate source and the date the rate was taken from it.
- Converted value, and which decision it governs (approval, reimbursement, or both).
- Approver identity and timestamp.
- Entity and cost center that owns the cost.
- Reimbursement status and payment date.
- Export or sync reference into the accounting system.
The test for this list is simple: hand it to someone who was not involved, twelve months later, and see whether they can explain the number without contacting the submitter. If they can, the workflow is doing its job. If the answer requires a person, the evidence is in someone’s memory rather than in the record.
Two of these are the ones teams most often skip. Transaction date separate from submission date matters because employees submit in batches — a trip expensed three weeks later has a transaction-date rate and a submission-date rate that can differ materially. Rate source recorded per claim, not per policy matters because policies change; a claim from before the change has to carry the rate source that was in force at the time, not the current one.
For the field-by-field version of this, see expense audit trails. For the accounting mechanics of the difference between the booked and settled rate, see foreign currency expenses.
Cards and accounts are not the whole workflow
Search for multi-currency expense management and most results explain it through card programmes, multi-currency accounts, and payment rails. Those are real and useful — holding a balance in a currency avoids one conversion. But they solve the payment leg, not the expense leg.
A card programme does not tell you whether a claim was inside policy. A multi-currency account does not route an expense to the right approver, does not record why an exception was allowed, and does not map the cost to the right entity. Companies that solve only the payment leg tend to discover the gap at audit, when the question is not "how did the money move?" but "why was this approved, and by whom, at what value?"
There is also a coverage problem. Card and account products cover the currencies and countries they cover. Reimbursement has to cover wherever an employee actually spent money, which in a distributed team is not a list anyone controls in advance. A workflow that only works when the employee used the company card leaves the awkward cases — a contractor, a new market, a personal card used in an emergency — to be handled by email.
The practical position: treat cards and accounts as one payment mechanism within a workflow, not as the workflow. The expense lifecycle — capture, policy check, approval, reimbursement, reporting, audit — has to work regardless of how the employee paid.
Connect FX handling to approvals and entities
Rate policy stops being a standalone topic the moment approvals get involved.
Approval thresholds are expressed in some currency. If they are maintained per currency by hand, they drift as rates move, and two employees in different countries end up under different effective policies without anyone deciding that. The durable pattern is to define the threshold once, in a reporting currency, and convert each claim into it with the recorded rate — so the routing decision and the reimbursement amount rest on the same number. Automated expense approvals covers the routing side.
Entity ownership is the other coupling. The functional currency that governs the accounting treatment belongs to the entity, not to the employee. An employee of one entity incurring a cost that belongs to another is both a routing problem and an FX problem, because the two entities may translate the same expense differently. See multi-entity expense management and, for the recharge itself, intercompany expenses.
Treated separately, these three produce three sets of rules that contradict each other at the edges. Treated as one operating model, the rate, the approver and the entity are all decided at submission, from the same record.
How Clara handles multi-currency expenses
Clara Global lets employees submit expenses in any country and any currency, from the same platform the finance team already uses. The employee submits in the currency they spent in — there is no conversion step for them to get wrong.
The rate applied is the one for the date of the transaction, and it is fixed onto the claim the moment the employee submits. That is the point of the design: the value the employee sees, the value the approver signs off on, and the value that appears on the reimbursement record are the same number, drawn from a known date and a known source, rather than recalculated at each handoff.
For finance, the output is a payment-ready report rather than a queue of claims: expenses grouped by currency and by the bank account they need to be paid from, with the FX breakdown included. Clara does not execute the transfers — the report is designed for a finance team to act on through the banking platform they already use.
What that changes, concretely, is where the reconciliation work goes. Instead of rebuilding the rate story per claim at month end, the rate is part of the claim from the start, and the report is grouped the way the payment actually has to be made.
Moving off the spreadsheet without a six-month project
Most teams do not need to solve everything at once. A workable order:
Write down the rate policy you already have
Which rate governs reimbursement, which source, and on which date. Most teams have an unwritten answer already; writing it down changes nothing operationally and immediately makes claims comparable.
Separate transaction date from submission date
In whatever you use today. This is usually a one-column change and it removes the most common source of unexplainable differences.
Record the rate source per claim
Not per policy document — on the claim itself, so a historical expense carries the rule that was in force when it was made.
Define thresholds in one reporting currency
Stop maintaining per-currency bands by hand.
Group the payment output by currency and destination account
Even in a spreadsheet, this is how the payment actually gets executed; matching the report to the mechanism removes a manual sort every month.
Then move the workflow into a system
By this point you know your own rules, which makes configuration a transcription exercise rather than a design project.
Teams that skip straight to step 6 usually end up configuring a system around rules they have not agreed on yet, and then relitigating them in the tool.