Skip to main content

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.

Comments

Popular posts from this blog

Start Here

Something in Business Central not behaving? Work down this page. Most things are answered here already — and if they aren't, the last section tells you exactly what to send me so we can skip three rounds of questions. The sixty-second checks These four clear most of what reaches me. Try them before anything else. Hard refresh the page. Hold Ctrl and press F5. A normal refresh reloads the cached copy; this one doesn't. Check which company you are in. The name is at the top of the screen. Posting into the wrong entity is easier than it sounds. Open it in a private window. If it works there, the problem is cache or a browser extension, not Business Central. Try a different browser. If Edge fails and Chrome works, that alone narrows it down enormously. Part 1 — Something on screen isn't working A page won't load, a button does nothing, something has gone missing, or an error stops you posting. Start here if Business Central itself is misbehaving. A...

Foreign Currency Revaluation in Microsoft Dynamics 365 Business Central

Microsoft Dynamics 365 Business Central (BC) allow users to account for foreign currency transactions. BC also able to translate the registered foreign currency amount into functional currency that setup in the entity using the conversion rates which setup in Exchange Table.   Due to the exchange rates fluctuate constantly, as a dollar worth in foreign currency today might not equivalent to the same foreign currency worth the next day. Hence, users are required to adjust the open documents that transact in foreign currency which include open invoices, credit memos, and advance payments. Once the open documents transacted in foreign currency is revalued, the gain and loss which calculate after comparing the closing rates at the period end will be posted to profit and loss as unrealised gain and loss, ensuring that the subledgers and general ledger can be reconciled.   This process can be done using Adjust Exchange Rate in BC, a batch job to adjust the exchange rates fo...

Exchange Rate Adjustment in Dynamics 365 Business Central: Unrealized Forex Gain/Loss

Overview Business Central's Exchange Rate Adjustment revalues your open foreign-currency documents and bank balances at month-end and posts the unrealized foreign exchange gain or loss for you. You enter the month-end rate once, run one batch job, and BC handles every customer, vendor and bank account in that currency. Why it matters: under MFRS 121, foreign-currency monetary items such as receivables, payables and bank balances must be translated at the closing rate at each reporting date. The difference from the amount originally booked is an unrealized gain or loss that belongs in that period's P&L. Which version are you on? In newer versions of BC the batch job is called Exch. Rate Adjustment and includes Preview Posting, Adjust per entry and the Exch. Rate Adjmt. Ledger Entries page. Older versions use the Adjust Exchange Rates report, which works the same way but without those options. Search for "exchange rate" in Tell Me to see which one your co...