Anyone have ideas on implementing multi currency in TurboCASH Accounting?
Each time I look at this it becomes more complex. I have been fight "bloat" in TurboCASH for 30 years. The last thing we want is more complexity.
The best I have so far is keeping a separate set of books for each currency and making journal entries when required!
This problem is going to get more complex as we try to deal with crypto currencies and hyper ledger. We have some time to breath at the moment, but if we stand still this will engulf us.
If you have strong ideas on solving this please join the group
All contributions welcome.
I haven't used TurboCASH in a while but have administered/implemented multi-currency accounting
systems in the distant past and as a result the following are just some initial thoughts. Apologies for any non-TurboCASH terms used.
Whilst I appreciate the desire to avoid more complexity. Moving from single currency to multi-currency adds complexity by it's nature. The choice is between absorbing the complexity within
the system or loading it on to the user. The more currencies used and the greater frequency of
transactions with different currencies then the more desirable it is that the system handles it.
A key requirement is the ability to record transactions in a number of currencies whilst enabling
reporting to be made in a reporting currency. Typically purchases could be made in a number of
currencies dependent on the national diversity of the supply chain whilst sales are likely to be
made in a smaller number of currencies. So the Purchase Ledger staff may want to see the creditors on
a real-time basis in the currency owed whist the Accounting staff might well want to see the total
value of the creditors in the 'reporting' currency at the end of the period.
Each transaction, therefore, has a 'Transaction Currency' and a 'System Currency' and corresponding
values. The system needs to hold different Transaction Currencies and an exchange rate between each
Transaction Currency and the System Currency applicable on a particular date. Local purchases would
have the same currency and values for both Transaction and System.
It wouldn't be practical to update the exchange rates on a real-time basis and so a more manageable
practice could be to use the exchange rates at the close of business on the final day of the accounting period. These exchange rates could be used for the following month's transactions. At the end of the period it would be necessary to revalue all currency items to the new rate to recognise the new value of the asset or liability. The other side of the transaction would be to an account that holds 'unrealised' currency revaluation adjustments. Differences in values received/paid on the liquidation of assets and liabilities would be to an account to hold 'realised currency adjustments'.
I've only skated the surface and what detail included is for illustration purposes.
Thanks for the answer.
TurboCASH has a really simply export and import of transactions, so this could easily be implemented in two or sets of books running simultaneosly over the same periods.
This is how I currently run these situations and like you said it gets complicated.
This way allows those that don't have multi currecy problems to use TurboCASH without ever having to worry about it.
1) The books carry the same chart of accounts.
2) bank accounts, debtors and creditors are grouped by currency. in each set of books.
3) at what ever period required for reporting the batches are exported, multiplied by the exchange rate of choice and reposted.
4) Any cross currency transactions - invoices in one currency, received in another are - corrected with a n journal to gain or loss on forex.
The question is do we bring it directly into TurboCASH or not? The data base is designed to accept multi currency, but structuring the reports would be really complex.