Business Central: Why Forex Gain/Loss Is Wrong When Applying a Foreign Currency Payment to an Invoice in Local Currency with same equivalent

Symptom: You post a Cash Receipt Journal in a foreign currency, key in the actual bank rate directly on the line, and the receipt posts correctly. Then you apply that receipt to the customer's invoice (recorded in Local Currency) — and Business Central posts a forex gain/loss that shouldn't be there at all. It looks like the customer paid more (or less) than what actually landed in the bank.

The scenario

• Local Currency (LCY): GBP
• Invoice: GBP 1,000
• Customer pays: USD 1,346.39 — the bank-negotiated rate that day meant this USD amount exactly covers the GBP 1,000 invoice, no more, no less.

Expected result: Payment = Invoice. Applying the receipt should close the invoice with zero forex gain/loss.

What actually happens: after applying, Business Central posts a gain or loss anyway, and the receipt's own Amount (LCY) changes in the process.

Why this happens

You post the Cash Receipt Journal with Currency Code = USD, and use Change Exchange Rate (the AssistEdit on the exchange rate field) to key in the actual bank rate for that day — the rate that makes USD 1,346.39 equal exactly GBP 1,000. The receipt posts at GBP 1,000.00. Looks perfect so far.

But Change Exchange Rate on a journal line only sets the rate for that one posting. It does not write a dated row into the master Currency Exchange Rates table for USD.

When you later apply the receipt to the invoice, Business Central doesn't reuse the Currency Factor baked into your already-posted ledger entry. It does a fresh lookup against the Currency Exchange Rates table for USD as of that date. If no rate exists for that exact date, BC falls back to the most recent earlier dated rate it can find — a generic or stale rate that has nothing to do with what your bank actually gave you. That fallback rate, not your bank rate, drives the recalculation at application, and that mismatch is the gain/loss you're seeing.

How to confirm this is what's happening:

Go to Currencies → USD → Exchange Rates and check whether a rate exists for the receipt's posting date.

• If your bank rate is sitting there → the override persisted, and this shouldn't be happening from this cause — look elsewhere.
• If no rate exists for that date at all, or a different rate is shown → that's the root cause. Your line-level override never made it into the master table, so the application step pulled a fallback rate instead.

The fix

Before posting (or at least before applying) the receipt, create the actual dated exchange rate record — don't rely on the line-level override alone:

1. Go to Currencies → USD → Exchange Rates → New line.
2. Starting Date = the receipt's posting date.
3. Exchange Rate Amount = 1
4. Relational Exch. Rate Amount = 0.742727 (this is GBP 1,000 ÷ USD 1,346.39 — the rate that makes them equal)
5. Leave Relational Currency Code blank (defaults to LCY).

With a real dated row in place, both the receipt's own posting and the later application lookup pull the same rate. USD 1,346.39 converts to GBP 1,000.00 both times — invoice and payment match exactly, and no gain/loss posts on application, exactly as expected.

Fixing entries that are already posted wrong

If a receipt is already applied and the wrong forex has posted:

1. Unapply the entry from the customer ledger entries.
2. Insert the correct dated exchange rate (as above).
3. Reapply, so the reapplication recalculates against the right rate.

Be careful doing this in a closed or already-reported period — unapplying and reapplying reverses and reposts the realized gain/loss entries. Test the sequence in a sandbox company first.

---

Have a similar multi-currency application quirk in Business Central? Drop a comment below — happy to help troubleshoot.