Foreign currency is where otherwise smooth expense processes revert to manual work. An employee travels, pays in euros or pounds or pesos, and comes home with receipts in one currency while the card statement shows charges in another. The two numbers describe the same purchase but will never be equal, because a conversion rate and usually a card network margin sit between them.
In most processes, reconciling the two falls to a human with a spreadsheet: look up a rate for the purchase date, convert the receipt amount, decide whether the difference from the statement charge is normal FX spread or an actual problem, and record something defensible. Multiply across a travel heavy team and foreign expenses become their own month end sub project, one that produces inconsistent rates, undocumented conversions, and matching that depends on whoever did the math that day.
None of this requires a human. It requires the conversion, the matching, and the documentation to be built into the flow.
Conversion at the Day's Rate, Both Amounts Kept
When Finofo reads a foreign currency receipt, the amount is converted at the day's rate, and both amounts are kept on the expense record: the original currency amount from the receipt and the converted amount. The exchange rate used is visible on the expense itself.
Keeping both amounts matters more than it sounds. The original amount is what matches the physical receipt an auditor might inspect. The converted amount is what posts to the GL and compares against the statement charge. A record that keeps only one of the two forces someone to reconstruct the other later; a record that keeps both, with the rate, answers every future question at a glance.
Matching Across Currencies
Receipt to statement matching uses merchant, amount, currency, and date together, which is what makes cross currency matching workable.
The amounts will not be equal, and that is expected
A EUR 64.00 receipt and the corresponding CAD statement charge differ by the conversion, and the card network's rate rarely equals the reference rate exactly. Matching that demands equality fails on every foreign transaction. Matching that understands currency treats the small conversion gap as the normal case, links the pair, and reserves attention for differences that exceed what conversion explains.
Variances get flagged before the expense moves on
Where the gap between converted receipt and statement charge is larger than FX spread accounts for, a dynamic currency conversion markup, a hidden fee, an outright error, the variance is flagged before the expense moves downstream. The exceptions surface individually and immediately, not as an aggregate mystery in a month end reconciliation.
What Posts Is Already Clean
By the time a foreign expense reaches the accounting system, the conversion is documented, the match to the statement is made, tax captured off the receipt is carried per line, and the entry is coded like any domestic expense. There is no separate FX worksheet feeding the close, no manually keyed rates to second guess, and no pile of foreign receipts waiting for someone with time and a currency table.
For companies whose people cross borders regularly, this is the difference between international spend being a special category of monthly effort and being ordinary expenses that happen to have two currencies on the record. It also fits the broader platform naturally: Finofo's payment and treasury layer is multi currency at its core, so expenses are simply one more flow where currency is handled as a native property rather than an afterthought.
Start Here
Watch what happens to the next batch of travel receipts your team processes. If a spreadsheet with exchange rates appears at any point, that is manual work the flow should be doing.
Finofo converts foreign receipts at the day's rate, keeps both amounts with the rate visible, matches across currencies, and flags real variances, so international expenses post as cleanly as domestic ones.
