Foreign Currency Valuation Posting To The Wrong Account

The controller reviewing the month end P&L notices an unrealized exchange gain or loss sitting in an account that has nothing to do with the business it relates to, or split across two accounts when it should be in one. Sometimes it surfaces as a note from the accounting team that says the valuation of open vendor invoices posted to a generic other income account instead of the dedicated unrealized FX gain account used by the rest of the entity. In parallel ledger environments it shows up as the valuation posting landing under the leading ledger's local GAAP account when the run was meant to value the parallel IFRS ledger, or vice versa. Nobody thinks configuration first; the first assumption is that the valuation run picked the wrong exchange rate, and someone reruns it expecting a different result, which changes nothing because the account, not the rate, is wrong.

Pull the valuation run log for the specific run ID, company code, and valuation date from FAGL_FC_VAL or F.05, filter to the line items posted against the account in question, and compare the account determination key shown in the log against the assignment in OB09 and OBA1 for that reconciliation account and chart of accounts. A mismatch between the key the log used and the key the business expects for that account confirms the cause without needing to touch the posting itself.

If the exchange rate difference key or its OBA1 account assignment is wrong, that is a configuration change and needs a transport through the normal change path, it is not something to patch directly in production. If the G/L account master is missing the valuation grouping value, that is a master data correction on FS00 and can usually be applied directly, though it should still go through whatever master data control process the client uses since it changes future valuation behavior. If the valuation area to ledger mapping is wrong, that is configuration and requires careful sequencing since changing it mid-cycle affects both ledgers' postings, best done at period boundary with both ledger owners aware. In every case, correct the configuration or master data first, then let the next valuation run's automatic reversal of the prior period's valuation clean up the balance; only if the wrong postings have already been reported externally does a manual correcting entry become necessary, and that entry should be flagged clearly as a one-off correction, not a workaround for a recurring problem.

The reflex fix is a manual journal entry reclassifying the amount from the wrong account to the right one, closing the immediate reporting gap. It fails because the valuation run automatically reverses its own prior posting at the start of the next run; the reversal hits the same wrong account the original posting did, not the account the manual entry moved the balance to, so the manual correction and the automatic reversal now disagree and someone has to unwind both in the following period. It also leaves the underlying account determination untouched, so the same account is wrong again next month.

The FI general ledger configuration owner holds OB09 and OBA1 assignments and any ledger to accounting principle mapping; changes go through transport with a change record. Master data changes to the G/L account's valuation grouping sit with whoever governs chart of accounts master data. The handover note should record the account, the key involved, the config values before and after, and whether a manual correcting entry was posted alongside the fix.