I understand from the Adjust Exchange Rate function, you can’t really see what is the impact before you go ahead with it, once posted, it is irrecoverable. I have financial experience and background, so I am asking myself this question, if I perform this unrealised exchange gain/loss revaluation, how can I easily reverse back the journal on the first day of the following month.
Someone might say, well, you don’t have to do that as system will reverse for you before you actually realise it by posting a payment. Yes, you are right if the invoice will be paid in the following month, otherwise, the accounts will not be accurate. So usually, as a finance, we will reverse everything on the first day of the following month, after some realised payments being made, we do not have to bother, end of the new month, we will do another “unrealise exchange gain/loss” to get the new unrealise figure.
Does anyone has an idea on how to achieve what I was asking above? I know if I can have a journal of these unrealise exchange gain/loss journal without posting directly, that will be great, as I can paste it to a recurring journal which can reverse for me on the first day of the following month.
Inaccurate the accounts will be in case you somehow reverse (which is not possible in NAV without modifications) the adjusting entries.
AER batch job is intended for use at the same date and frequency as your company prepares trial balances, say, end of month, quarter or year (financial year), to reflect the Db or Cr debts in LCY for open transactions in foreign currencies. Running AER with other posting dates is useless from accounting point of view.
Theoretically, it could be run even daily, but it makes sense only if company has large amount of outstanding balances in foreign currencies, especially in non-stable markets and “exotic” currencies with unpredictable and fast FOREX rate changes. The latter case usually is solved by issuing invoices in reliable currencies like USD, EUR, JPY, CHF, you name it, rather than, say, Zimbabwean dollars.
Besides, it does not matter WHEN the payment is made - “following month” or whenever. When payment is applied, NAV calculates and posts correct gains/losses as of date of transaction, given the FOREX rate is entered in system for that date. (if not, NAV uses earliest known rate before posting date), and it does not matter at all have you run AER and how many times it was done in between the invoice posting date and finally applying a payment at some later date to it.
You are in a way correct, but that was the typical way of handling Unrealized Gain/Loss in Singapore as to reverse them and unrealized again on the following month if unpaid, so that the previous month won’t have any unrealized. But you did not answer my question about how to easily reverse the thing…
Adrian, I wrote already that possibility to reverse means full recoding of AER batch job, moreover, the principles and algorithm must be changed completely.
AER in NAV is designed as ongoing process, every time you run it a differential correction is made against already posted entries, if FOREX rate has changed from previous run. Therefore, if you could “rollback” the last correction, you’ll be left with incorrect balance in LCY (correct as of previous run date, but as of “today” outdated), if some earlier corrections are still present. Even worse the results would be, if you could rollback some entries in the middle of consecutive positive-negative corrections chain - then the open transactions balance in LCY would go completely nuts…
This is the reason why AER results are posted immediately, excluding the possibility for user to review the postings in the prepared Journal. If the user was allowed to tamper with amounts before posting, results would become inaccurate, only deleting some entry completely would be acceptable, thus leaving that one transaction unadjusted.
Some companies do not run AER at all except once at the last day of their FY for yearly balance sheet to be realistic (actually this is a legal request in all the countries I’ve happened to work in). So they avoid big turnover in gains/losses accounts, if for some reason they do not like this turnover to be present.
You may calculate the corrections manually, and post them as recurring journal with next day reverse option, but this is annoying job and place for easily making errors… This could be reasonable for large amounts, say, bank loans in foreign currency measured in millions, as for such amounts even slight FOREX rate shifts make significant differences in LCY.
LOL, actually I am just trying to find out more in case I meet with a nasty accountant posting question to me. For accounting standards, usually before FY is acceptable, usually it is only a company policy if requires user to do it monthly. Thanks.
In addition to being a NAV professional, I’m not a nasty accountant, but chartered one. Living in ERP world for almost 30 years and not having an idea of accounting theory would be a nuisance,
Haha, yuh, but you would be surprise that I have met various Accounting Managers who has limited knowledge in concepts, during data migration stage, an Accounting Manager can provide me with a Trial Balance that does not balance for my import hohoho.