Hi Singapore,
I can understand that your partner is a little uneasy on this. But, it is true that you can do adjustments... the question is what will be adjusted. As a rule of thumb:
- bank accounts: "Adjust Exchange Rates" will post the resulting difference in balance to date. This works as long as you re-run the adjustments from the earliest backdating to to the last date you have run (and posted) exchange rate adjustments, according to the exchange rate adjustment register.
- customer/vendor ledger entries: "Adjust Exchange Rates" will post unrealized gain/loss amounts where necessary by entry, and matching reversing amounts at every application after the valuation date. So this will work, but also the re-run of all adjustments after the backdating is required.
But here is a catch, too: Customer/Vendor ledger entries are the result of an invoice posting or a payment. You will have g/l accounts in the transactions belonging to these entries that will not be adjusted (revenue/cost, VAT, other balance accounts than A/R and A/P). These entries, once posted with an exchange rate, will remain as they are. A backdating of the exchange rate doesn't change them, but makes the previous postings effectively wrong. If the deviation is by orders of magnitude (wrong decimal point in an exchange rate), this can lead to significant distortions of your PnL.
We had this issue a few years ago, the solution was to post a corrective general journal, distributing the exchange rate adjustment effects back to the non-adjusted accounts that where part of the "wrong exchange rate" transactions, by transaction. I created a special batch to generate this journal... it was not easy.
Fortunately we didn't have items (all postings with g/l accounts). If you have items, the problem is bigger... you would need to revaluate the purchased (and sold) items with the wrong exchange rates. Best would be to do this with item charges.
Also, to avoid "decimal point" errors while entering exchange rates, we have introduced a change threshold against the previous rate where the user needs to confirm the new rate. Importing them directly from the bank is even better, we implemented this later on.
Back to what you can do: If the backdated exchange rates were only slightly wrong (a few percent, resulting in a non-relevant amount) then I would do the adjustments that are built-in in the system. If it was more, you need to make the adjustment and the distribution back to the PnL/VAT accounts affected. You can do this with a manually entered general journal, but it depends on how detailed the correction should be.
with best regards
Jens