Why won't my foreign-currency bank account reconcile, and how do I record the exchange-rate difference?

Why does the account refuse to tie when every transaction is there?

Because the same money is being measured twice, in two currencies.

The bank statement reports the balance in the account's own currency. Say it is a euro account. Your books carry that account in the dollar, which for a U.S. business that earns and spends mainly in dollars is also what U.S. accounting standards (ASC 830, Foreign Currency Matters) call the functional currency: the currency of the primary economic environment in which the business operates. This article assumes the two are the same.

Every deposit and payment enters the ledger in dollars at the rate on its own date. The rule is that a foreign-currency transaction is measured initially in the functional currency using the exchange rate in effect on the date it is recognized. As a convenience, an appropriate weighted-average exchange rate may be used for income statement accounts. So the dollar balance of the account is the sum of amounts converted at many different rates. The statement holds only euros. Multiply the euro balance by any one rate and you get a figure that matches none of those historical conversions, unless the rate never moved.

ASC 830 then requires a second measurement. At each balance sheet date, recorded balances denominated in a currency other than the functional currency are adjusted to reflect the current exchange rate. A cash balance in euros is such a recorded balance, as are receivables and payables fixed in euros — the items professional guidance groups as monetary. Until that adjustment is posted, the dollar ledger will not match the euro statement at today's rate, and the gap is the accumulated rate movement.

That gap is a measurement effect, not a missing transaction. Hunting for an item that does not exist is how these reconciliations eat an afternoon, and it usually ends with a plug entry made just to stop the search.

How do you prove the gap is the exchange rate and not a missing item?

Do not take the conclusion on trust. A missing deposit and a rate movement look identical when you compare only two dollar totals. Run a two-step test instead.

Step one: reconcile in the account's own currency. Take the statement's ending balance in euros and the ledger balance of the same account in euros. Tick off deposits, payments and outstanding items exactly as you would for any bank reconciliation, but with every amount in euros. If your system stores the foreign amount on each transaction, run the account register in that currency. If it records dollars only, build a schedule listing each transaction's euro amount next to the dollar amount posted and the rate used.

Step two: read the result.

• The euro balances agree. Every transaction is present in both records. The remaining dollar gap comes from the rate. Confirm it: the euro balance multiplied by the period-end rate, minus the dollar ledger balance, is the whole of the difference between the ledger and the statement valued at that rate. If you had been comparing the ledger with the statement converted at any other rate, redo that comparison at the period-end rate before concluding.
• The euro balances do not agree. You have a genuine reconciling item, such as a missing, duplicated or mis-keyed transaction. No rate adjustment will fix it. Find and correct it first; diagnosing a reconciliation that fails for reasons unrelated to currency is a separate question.

Two shortcuts defeat this test. Reconciling only the dollar balance merges item errors and rate effects into one number, so a real missing deposit can hide inside what you have decided is a rate difference. Forcing the gap to zero with an entry to suspense or to cash misstates cash, keeps the currency effect out of the accounts where it belongs, and brings the same gap back larger next period.

Which exchange rate and which date should you use?

Each measurement has its own rate date.

• When a transaction is recorded: The rate in effect on the transaction date. FASB Statement No. 52 put the test this way: the rate at which that particular transaction could be settled on the transaction date is used to record it.
• At period end. The current rate at the balance sheet date, which is the last day of the period you are closing. For that date, the current rate is the rate at which the related receivable or payable could be settled on that date.

The acceptability test is in ASC 830's wording: a rate at which the amount could actually have been exchanged on that date. Pick one source that meets it, use it consistently, and record the source, the rate and the rate date on the entry or its attachment. Without them nobody, including you at next year's close, can re-perform the entry, and the gain or loss becomes whatever a convenient rate happened to produce.

When your bank or payment provider did the conversion. If the provider converted the money, the dollar amount it actually debited or credited is the settlement of that transaction. Record the transaction at that amount, because that is the rate at which it was in fact settled. Provider rates are not reference rates; Microsoft's documentation for its Business Central accounting system notes that bank currency rates always differ from official rates. If you later restate a held balance at a reference rate, part of the difference reflects the provider's pricing rather than pure market movement. That residual is still recognized as a gain or loss. It is not reconciled away. A conversion fee the bank states separately is a bank charge, which is a separate topic.

How do you record the period-end restatement?

A foreign-currency transaction gain or loss generally goes into net income for the period in which the exchange rate changes. For an ordinary bank balance, receivable or payable it belongs on the income statement: not in a suspense account, not in equity, and not buried in cash.

The calculation takes three numbers:

1. The foreign-currency balance per the reconciled ledger (which, after step one, equals the statement).
2. The period-end rate from your recorded source.
3. The dollar balance of the account in the ledger before the entry.

Restated balance = foreign balance × period-end rate. Adjustment = restated balance − ledger dollar balance.

• If the adjustment is positive, debit the bank account and credit foreign exchange gain or loss.
• If it is negative, debit foreign exchange gain or loss and credit the bank account.

Keep the effect in a dedicated account, such as "Foreign exchange gain or loss", rather than netting it into sales or bank charges. The account ties out either way, but a dedicated line lets you see whether currency movement or trading is driving the month's result.

What changes when a foreign-currency invoice or bill is paid?

Two kinds of difference exist, and they are recognized at different times. FASB Statement No. 52 describes transaction gains and losses as changes in the actual functional-currency cash flows realized upon settlement of a foreign-currency transaction, and changes in the expected cash flows on transactions not yet settled.

• A balance still held, such as the cash in the euro account or an invoice not yet paid, is restated at each period end. The difference is unrealized: the money has not yet changed hands at the new rate.
• An amount settled or converted, such as a customer paying a euro invoice, produces a realized difference. That difference is included in net income for the period in which the transaction is settled.

Here is how the settlement difference arises. You invoice a customer in euros, and the receivable enters the books in dollars at the invoice-date rate. The customer pays the full euro amount weeks later, when the rate is different, so the dollars the payment is worth differ from the dollars on the receivable. The customer has paid in full in the invoice currency and owes you nothing. Clear the whole receivable and post the difference to foreign exchange gain or loss. Leaving a few dollars open on the customer's account, or writing it off as a discount, misstates both the receivable and the result. Bills you pay in a foreign currency work the same way in reverse.

If the invoice stayed open across a period end, the receivable was restated at that date along with the cash, because receivables are monetary balances too. The settlement difference is then measured from that restated amount, not from the original invoice rate. Otherwise the part of the movement already recognized at the period end would be counted twice.

If you convert at every transaction instead of holding the currency. Some businesses have no foreign-currency account. Foreign receipts are converted and deposited straight into a dollar account. The bank statement and the ledger are then in the same currency, so there is no held balance to restate and no recurring cash restatement to post. Differences arise only when a foreign-currency invoice or bill settles, and they are recorded as above.

What does the whole cycle look like with numbers?

The rates below are invented for illustration. The books are kept in dollars and the bank account is held in euros.

March, a held balance.

The March statement shows EUR 6,000.00. Step one passes: the euro balances agree. At the March 31 rate of 1.12, the balance is worth 6,000 × 1.12 = 6,720.00 dollars. The ledger shows 6,400.00, so the gap is 320.00, all of it rate.

After posting, the three balances line up. The statement shows EUR 6,000.00. The ledger shows EUR 6,000.00. The ledger's dollar balance is 6,720.00, which is exactly 6,000 × 1.12. The euro reconciliation explains every item, and the restatement explains the dollar figure.

April, a settlement and a held balance in the same account.

On April 4 you invoice a customer EUR 5,000.00 at 1.11, so the receivable is 5,550.00 dollars. On April 24 the customer pays EUR 5,000.00 into the euro account. At that day's rate of 1.09 the receipt is worth 5,450.00 dollars.

The receivable is cleared in full, and the 100.00 realized loss is recognized in April, the period of settlement.

At April 30 the account holds EUR 11,000.00 (6,000.00 + 5,000.00). The ledger's dollar balance is 6,720.00 + 5,450.00 = 12,170.00. At the April 30 rate of 1.10 the balance is worth 11,000 × 1.10 = 12,100.00 dollars, so the restatement is a loss of 70.00.

The ledger now shows 12,100.00 dollars for EUR 11,000.00, the statement's figure at the period-end rate. April's currency effect has two separate sources: 100.00 realized on the invoice and 70.00 unrealized on the held balance. Had you posted the receipt at 5,450.00 and then tried to explain April's whole gap with one restatement entry, 100.00 would have stayed on the customer's account. Had you posted the receipt at the invoice's 5,550.00 to clear the customer, one restatement of 170.00 would tie the bank, but the 100.00 realized loss would be mislabelled as an unrealized movement and, across a period end, recognized in the wrong period.

Does your accounting system restate the account for you?

Before you post anything, find out. Your task depends entirely on the answer.

If the system handles more than one currency and has a revaluation function, your job is to run it correctly and then check it, not to post a second entry. Dynamics 365 Business Central (Microsoft's U.S. documentation dated 16 June 2026) is one documented example. That documentation describes an Adjust Exchange Rates batch job that the user runs to adjust exchange rates for posted customer, vendor and bank account entries. Before running it, you must enter the adjustment exchange rates. For bank accounts it applies the rate valid on the posting date you specify, and calculates the difference for each bank account that has a currency code. It posts bank-account differences to the accounts named in the Realized Gains Acc. and Realized Losses Acc. fields on the Currencies page, while customer and vendor adjustments go to the accounts named in the Unrealized Gains Acc. and Unrealized Losses Acc. fields. A bank revaluation appearing in the realized accounts is therefore how Business Central is documented to post it, not an error. The operator's checks are the same in any such system:

• The rate entered matches your recorded source for the period-end date.
• The posting date is the period end.
• The gain and loss accounts it posts to are the ones you intend.
• After it runs, the account's dollar balance equals the foreign balance multiplied by that rate.

Posting a manual restatement on top of one the system has already made doubles the adjustment. The account then moves further from the statement, which looks as though the treatment is not working. If the account is out by exactly the amount you posted, look for a duplicated adjustment first.

If the system carries one currency only, nothing restates the account for you. Keep the foreign-currency schedule from step one, calculate the restatement each period, and post the entry yourself.

QuickBooks Online, Xero, Zoho Books and similar small-business systems were not checked for this article. For any of them, read the vendor's own current documentation for your edition before relying on it either way; whether and how a system revalues foreign-currency accounts varies by product and version.

Is the restatement a one-time fix or a monthly step?

It is a recurring close step. The rule applies at each balance sheet date, and exchange rates keep moving, so the Business Central documentation says currency equivalents need adjusting periodically. At every period end:

1. Reconcile the account in its own currency.
2. Take the period-end rate from your source and record it.
3. Compare the restated balance with the ledger's dollar balance as it stands, including last period's adjustment, and post only the difference.
4. Record settlement differences on invoices and bills paid during the period as realized.

Last period's adjustment needs one decision, applied consistently. Either leave it in place and post only the incremental movement each period, as in the April example, or reverse it on the first day of the new period and restate from the original transaction rates at the next period end. Both give the same balance. Mixing them, or reversing an entry the system has already reversed, leaves a stale adjustment behind. Some systems reverse automatically: for an open invoice, Business Central reverses the unrealized gain or loss when payment is applied and posts the realized gain or loss instead. If yours does this, do not reverse manually as well.