DESKTOP EDITION CLOUD EDITION SERVER EDITION GUIDES FORUM

Multi-currency and attachments


#1

Can I have an idea about when multi-currency and attachement will be implemented, please ?


#2

Multi-currency: still a few days before it’s polished enough to be usable, see main thread

Attachments: can’t give ETA for that but possibly by end of next month


#3

How does it work? it doesn’t give any possibility to add the rate we want. And also, when customers pay in a different currency, does receipt module take it into consideration


#4

Better wait a few days. I really don’t recommend using multi-currency until everything is sorted out and documented.


#5

My 5 cents worth on this topic is that I am not sure why you would want to use a multi currency inside your accounts.

For Australian purposes, if you open a foreign currency bank account and include as part of your accounts, you are entering a road of complicated transactions and serious accounting and tax issues.

I would strongly advise that you talk to your tax accountant. Just as an example, every transaction in that foreign bank account is classed as its own Foreign Exchange Realisation Event and every “event” is either a capital gain or a capital loss. ie, if you incur a bank fee, then on top of the fee, there is a “Forex Realisation Event” Gain or Loss based on a FIFO system. There are 5 Forex Realisation Event’s. I would suggest that you understand the measures contained in all of the following:
Division 775
Subdivision 960-C
Subdivision 960-D of the Income Tax Assessment Act 1997.

I am yet to see any software that can capture this in accordance with the Tax Act. The accounting process and the accounting function conflict in the process of capturing the data, so there will always be a double up of workload. It is just the way it is.

That is not a challenge, it is just my experience having dealt with businesses that were Australian Based, but had a bank account in Japanese Yen and another in US dollars. It was a nightmare…

However… I could be wrong…


#6

I appreciate your insightful comment.

Obviously for simplicity reasons, if business can avoid foreign currency, it should.

However, once foreign currency is involved, it cannot be ignored. And some businesses simply don’t have a choice. There could be loan accounts, customers who require being invoiced in foreign currency or suppliers who invoice in foreign currency and the list goes on. So this is not just about bank accounts.

The real challenge is to design an accounting software which is not adding any overhead to data-entry procedures when multi-currency is enabled. Bad multi-currency implementation in software coupled with a bookkeeper who doesn’t understand mechanics of multi-currency is simply recipe for disaster. Not to mention, typical multi-currency accounting software is severely constrained in types of entries you can do to record day-to-day transactions which leads to various workarounds and even more mess.

I did huge research on other multi-currency accounting packages and not even one had multi-currency done right, so I can see where you are coming from. But this is implementation detail. At some point, someone will get multi-currency right.

I can’t comment on those 5 forex realisation events yet. I’m aware of them but I’ve never looked at them in detail. Not sure what tax implications they carry but I’m keen to educate myself further and see what can be done about it. You gave me something to think about.