One sale, three exchange rates, and none of them agree
A customer abroad owes you 30 EUR. You invoice them, they pay, and the amount that lands in your account is not what your accounting expected. Nothing failed. No integration is broken. The difference is that the invoice and the payment happened on different days, and a currency moved in between.
Stripe's revenue recognition documentation walks through exactly this. An invoice for 30 EUR is finalised on 1 January when the rate is 1.20, so the books expect 36 USD. The customer pays on 1 February when the rate is 1.10, and 33 USD arrives. The 3 USD gap is not a mistake anywhere — it is recorded as a foreign exchange loss, because the rate that mattered was the one at the moment the money actually moved.
That is the rule worth carrying: for payments and paid invoices, the rate used is the one in effect when the funds moved, not when you raised the document.
Why one sale can involve three different rates
Three systems can each pick their own moment, and they are all being reasonable.
Your invoicing system picks a rate when it creates the document, because it needs to show a number to the customer and to your ledger.
The payment processor applies a rate when it converts the customer's currency into the one your account settles in — its own rate, at the moment of the transaction.
Your accounting software applies a rate when it books the entry, usually from a daily feed of its own.
Three moments, three sources, one sale. If you have ever tried to work out which of your three numbers is "right", the answer is that they are all right and they were answering slightly different questions.
The documentation also notes the case that removes the problem entirely: a one-off payment, or an invoice paid at the moment it is finalised, has no gap to open, so no exchange difference arises. Timing is the whole mechanism.
The part that surprises people about refunds
The same thing happens in reverse. If a payment and its refund are separated by days, the rate can move between them — and it can move in your favour. The vendor's own example is a customer paying 30 EUR when the rate is 1.20 and being refunded 30 EUR when it is 1.10: you received 36 USD and returned 33, so the difference lands on your side this time.
Which is the real point about currency drift. It is not a leak that always runs one way and can be plugged. It is noise with a direction you do not control, and the correct response is to measure and record it rather than to hunt it.
What to actually do
Stop trying to make the numbers match to the penny. They will not, and the hours spent are worth more than the difference. What you need is a line in the accounts where the difference is expected to land.
Give exchange differences their own account. Once foreign exchange gain and loss has somewhere to sit, reconciliation stops being an investigation. If the number in that account is small and stable, everything is working.
Invoice and collect close together where you can. Every day between finalising a document and receiving the money is a day of exposure. Payment links on issue, shorter terms for foreign customers, deposits — these are currency decisions as much as cash-flow ones.
Know your settlement currency and what happens outside it. Payments in a currency your account does not settle in get converted automatically. That conversion has a rate and often a fee inside it, and it happens whether or not anybody planned for it.
Do not let an automation "correct" the difference. A workflow that adjusts an invoice to match a bank line makes the ledger tidy and the audit trail worse. Record both facts and the difference between them, which is what the difference account is for.
Check the drift monthly, not per sale. Per sale, it is noise. Per month, it is a number that tells you whether your pricing carries enough margin for the currencies you actually trade in.
When it stops being cosmetic
Rounding differences on a handful of invoices are a bookkeeping detail. Two things turn them into a real problem.
The first is volume: hundreds of small conversions, each with a spread inside it, add up to a margin question rather than an accounting one — particularly if your prices were set in one currency and your costs sit in another.
The second is long payment terms. A 30-day term on a foreign invoice is a bet on a currency, taken by default, by a business that did not intend to take one. Same shape as the more familiar problem of not knowing when marketplace money actually lands, only here the uncertainty is the amount rather than the date.
If you want the map of which system locks which rate when, and where your current setup silently disagrees with itself, that is part of a process audit: $299, three business days.
Related: how to reconcile marketplace payouts without a connector deals with the other half of the reconciliation problem, where the amounts are bundled rather than converted.