Multi-currency reconciliation: how to tell an FX difference from a real one

You owed a supplier EUR 10,000. Your bank shows USD 10,847 left the account, the supplier says they were short-paid, and your accounting system — set to reconcile in dollars — flags the invoice as unmatched. Now you are staring at a difference you cannot explain. Nothing is actually broken. A multi-currency difference is almost never one number; it is three legitimate things stacked on top of each other — the exchange rate moved between the invoice and the payment, intermediary banks took a cut in transit, and the settlement date landed in a different period than the charge. Reconcile in your base currency and you can never tell which is which. The fix is almost boringly simple: match in the original transaction currency first, where the amounts should tie to the cent, then treat the converted difference as a foreign-exchange gain or loss, not a missing transaction. Here is the whole method.

Why a base-currency report makes everything look broken

The reconciliations that error out are the easy ones. The expensive ones balance to a number you cannot account for. In a single currency, a difference is a difference — a missing row, a short payment, a duplicate. Across currencies, the same gap can be three unrelated, perfectly legitimate things at once, and your base-currency view collapses all three into one unexplained figure. An operator on r/Accounting described exactly how an international wire does this:

Payment initiates, something in the correspondent chain takes a cut we didn't anticipate, the amount that lands is different from what we sent, the settlement date doesn't match the initiation date

The thread's answers were "Sounds like shitty processes" and a suggestion to find a provider with flat, upfront fees — fair advice for next time, useless for the wire you already sent. The reason it "breaks our reconciliation the same way every time," in the poster's words, is that the dollar figure on your statement is the end of a chain of independent changes. Pull them apart and each one has an obvious home — and none of them is the "unmatched transaction" your tool thinks it found.

The three things hiding inside one mismatch

Before you treat a multi-currency difference as a discrepancy, separate it into its parts. Almost every "the numbers don't match" in foreign currency is some mix of these three, and only one of them is ever an actual error to chase.

Reconcile in the original currency first

Here is the rule that makes the other three legible: never reconcile in your base currency until you have reconciled in the currency the transaction actually happened in. In the source currency, the invoice, the payment, and the receipt should agree to the cent — there is no rate in the way to blur them. So a difference there is a real one, and a difference that only appears after conversion is FX, not a missing transaction. That single ordering decision is what lets you tell the two apart.

1. Match in the transaction currency. Line up the invoice, the payment, and the receipt in their original currency — EUR to EUR, GBP to GBP. The amounts should tie exactly. If they do not, that is a genuine discrepancy — a partial payment, a short-pay, a duplicate — and you investigate it the ordinary way.
2. Gross up the fees as their own line. Book the full invoice amount, then post the wire charge, the intermediary deduction, and the FX spread as separate bank-fee and FX-expense lines. Never net them into the invoice — netting is what makes the invoice look "wrong".
3. Convert each side at its own correct rate. Book the invoice at the rate on the invoice date and the settlement at the rate on the settlement date, using one canonical rate source and cadence (see below).
4. Let the base-currency difference fall out as FX. After steps 1 to 3, the leftover gap in your base currency is the realized foreign-exchange gain or loss. Post it to that account. It is a result of the reconciliation, not an exception inside it.
5. Revalue open items at period-end. For invoices still outstanding at close, revalue the foreign-currency balance at the closing rate; the movement is an unrealized FX gain/loss until the cash actually moves.

The distinction in steps 4 and 5 — realized vs. unrealized — is the one piece of FX accounting worth internalizing: a realized gain or loss is locked in when the cash settles, an unrealized one is the paper movement on a balance still open at close. Most accounting systems can post both automatically if you turn the setting on — NetSuite, for instance, only books the revaluation if Revalue Open Balances is enabled on the account. Off by default, it quietly leaves your foreign balances frozen at old rates.

Anatomy of one foreign-currency payment
----------------------------------------
Invoice                 : EUR 10,000.00
  booked @ 1.0820       : USD 10,820.00   (AP, invoice-date rate)
Paid                    : USD 10,847.00   (settlement-date rate, incl. spread)
  base-currency gap     : USD     27.00   -> realized FX + bank spread
Wire fee                : USD     30.00   -> bank fees
Intermediary deduction  : taken from cash in transit -> supplier short-paid

Match test
----------
  original currency : EUR 10,000 invoiced = EUR 10,000 owed   -> ties
  base-currency gap : posts to FX gain/loss + bank fees, NOT "unmatched"

Fix the inputs that silently differ

The method above assumes your systems at least agree on the basics. In multi-currency they usually do not, and the drift is invisible until close. A controller running a 14-country month-end laid out the failure mode on r/Accounting, in a thread titled "12 currencies, 3 ERPs, and we still hand-key FX adjustments at month end":

each one pulls FX rates from a different source on a different cadence. NetSuite uses end-of-month rate, SAP uses average

That is the whole problem in one line: two correct systems disagree because they are converting with different rates, and no amount of re-matching fixes a rate mismatch. Another commenter's workaround — "We still do it outside the system but it's only one translation layer" — is the right instinct (one place where conversion happens), done by hand. Standardize these four inputs and most of the month-end FX scramble disappears:

• One canonical rate source and cadence. Pick a single FX rate provider and a single timing rule — daily close, month-end, or period average — and apply it across every system. Mismatched rate sources are the single biggest reason two right answers disagree.
• A currency code on every amount. Tag every figure with its ISO 4217 code — USD, EUR, JPY — never a bare number or a $ that could be USD, CAD, AUD, or SGD. A loose currency symbol in a CSV export also quietly breaks numeric parsing, so the amount stops being a number at all.
• Fees grossed up, never netted. Record the gross invoice and the deductions separately. The moment a fee is netted into an amount, the amount no longer matches anything and you are back to chasing a phantom difference.
• A per-currency clearing account. Hold in-transit foreign cash in a clearing account by currency until it settles, so the settlement-date lag lives somewhere visible instead of floating as an unexplained variance.

Where it still bites: platforms and wires

Two places make all of this worse — your sales platforms and the wires themselves. On the sales side, the payout is already converted before you see it. A store owner on r/ecommerce put the cost plainly:

Every time Shopify pays out in a non-USD currency, Stripe auto-converts and takes like 1-2% on top of everything else.

The payout you receive is net of an FX conversion and a conversion fee, layered on top of the processing-fee and refund netting you already untangle for every payout. Stripe documents the same split between the presentment currency and the settlement currency: you can only avoid the conversion by holding a balance in that currency. So reconcile the payout per currency, in its presentment currency, before you convert — the same order as everything else here, and the same discipline as reconciling any payout against sales.

On the wire side, the poster's "the amount that lands is different from what we sent" is the intermediary-fee chain plus the bank's spread. The lever most people miss is the charge option: paying OUR (you absorb every fee, the full amount arrives) instead of the SHA default (the chain deducts from the transfer in flight) makes the deduction predictable and bookable instead of a surprise on the supplier's end. A poster on r/Bookkeeping named the reconciliation cost of getting this wrong:

Between my bank's wide exchange rate spread and random deductions along the way, reconciliation has become a nightmare.

The thread's answer was to switch to a cheaper provider — reasonable for the cost, beside the point for the books. Reconciliation does not need the fee to be small; it needs it to be predictable and posted to a line, not silently shaved off the rate. As one commenter on a separate scaling thread put it, "the transfer itself usually isn't even the problem. It's trying to match everything afterward." The method above is the "afterward".

When a spreadsheet stops keeping up

A two-file, single-currency match is fine in Excel, and most reconciliations should start there. Multi-currency strains it: every match now carries a rate, a date, and a fee; the same close runs every month across a dozen currencies; and eventually someone has to show an auditor how a base-currency number was reached from a foreign invoice three rates ago. That is where hand-keyed FX adjustments — the exact thing the controller above was still doing — stop being sustainable. Forgiving matching on the keys, one documented rate source, and a process that records its own reasoning matter more than any formula. Whether you do that in a workbook, a script, or a tool that can read the files for you, the rule does not change: reconcile in the original currency, then let the FX fall out where it belongs.

← All writing