Best practice for multi-currency set-up

I’m struggling with setting up a chart of accounts for a company which has to use multiple currencies (e.g. USD, EUR, GBP).

Let’s say EUR is the main currency. But some invoices and taxes have to be accounted for in GBP. I would like to have a set of accounts written in GBP for this purpose to avoid the hassle of currency conversion if possible. There are also ‘real’ bank accounts in this currency available, for which there should be appropriate accounts in tryton.

How is this best reflected in the chart of accounts? Should the specific accounts have ‘secondary_currency’ set to GBP? However, as far as I understand the documentation I have found, this will only enable currency conversion to the main currency (EUR). Is this correct?

Can I set the currency of an account to GBP so that no forced conversion is taking place?

Thanks in advance!

1 Like

This is not possible. Tryton is build on the principal of a main currency for the accounting (this is a standard practice).

Yes this purpose is to force to have always a second currency value for the moves on those accounts. So it is good to book the activities of a bank account.
What Tryton is missing to be complete on this topic is a wizard to record the value change of such bank account in the company currency. Such wizard should take the balance in the second currency and compare it with the balance of the main company using the current rate. If it is different than it should create a move.

Thank you for the clarification!

So, do I understand correctly that for an account with secondary currency there are two balances available, one in the main currency and the other in the second currency?

If so, is it correct that the balance in the second currency is calculated from the moves in this second currency and the balance in the main currency from the moves converted to the main currency?
Which conversion rate is applied in this case? The rate valid for the date the move took place?

Yes, there is “balance” and “amount second currency”

Yes

No it is the sum of the debit-credit in the main currency.

The rate at the date of each move is used.

That’s why I said that we are missing a wizard to create a move that re-align both balance when rate changes.

Also I missed that we are also missing some helper when registering payment in a second currency for a invoice. Because for now, Tryton will automatically marks the invoice as paid only if the amount in the company currency matches. The other cases a write-off must be created. But when the second amount matches, we should have this created automatically.

I see!

This leads me to other questions:

In Tryton there seems to be an account connected to almost any entity (e.g. a party has an account, when creating an invoice an account is needed, for payment methods, etc.

However, it seems only in rare cases an account of type ‘other’ (which can have a second currency assigned) can be used. In most case an account of type ‘receivable’ (or similar) needs to be chosen.

  • When are these accounts used and for what purpose?
  • How can I best ensure that payments for specific companies (who happen to pay in a foreign currency) are directly tied to accounts with a matching second currency?

While I’m not terribly good at programming I could give it a shot at writing an appropriate wizard (and helper). It would be very helpful, though, if I could work from an existing wizard as a blue-print. Is there something you can recommend as a starting point?

Thanks!

It is not because an account is not configured with a second currency that move on it can not fill the second currency.

If it is about receiving payment, it is not up to you to ensure the currency. You will see in which currency the customer will pay you. And if there are rate conversion issue, it is again up to you to decide if you accept it by recording as conversion lost or if you consider they should still pay the difference.

If it is about the company paying a supplier, the account_payment module takes care of the second currency registered on the move line and of the currency of the payment journal.

Thank you for your answer!

In general I agree with what you have stated.
However, I think we have a special use case here: certain companies get their invoice stated in their currency (e.g. GBP) from us. They pay these invoices in their currency to a bank account written in this specific currency.

In Tryton I would like to achieve that these customers are tied to a special account in Tryton with GBP set as second currency. Any moves in the ‘real world’ will always be made in GBP, so the ‘amount second currency’ should always reflect the correct balance (in GBP). Any discrepancies due to changing conversion rates can be balanced manually (e.g. as conversion loss), e.g. once every booking period.

If I understand your previous answers correctly, this should be doable with a Tryton account with the second currency set to GBP, as long as I make sure that all related moves are stated in GBP. The point where I struggle is to set up e.g. a payment method tied to an account with a second currency. It seems to me that accounts defined in payment methods cannot be of type ‘other’, which is the only type which can have a second currency, if I’m not mistaken.

Do I miss something here?

Well this is against the accounting rules. Everything in accounting should be done in a unique currency or you must have two separate accounting.

No, you do not need to set receivable account with a second currency because move on it will have a second currency if you post an invoice in a different currency.

Again this is not correct for accounting. You have to always struggle with the currency conversion.

IWell you can set a second currency on the account of a payment method. But that’s true the payment wizard does not enforce to use a payment method with accounts with the right second currency if the currency of the payment is not the main one. But it is not a big deal as the accounting constraint will prevent to end the wizard.

There is no constraint on accounts of payment except not being view: modules/account_invoice: 5bf1fbfdee8d invoice.py

Thanks for your answer!

Hmm. The accounting software I have used so far (Banana 8 and 9) allows just that. As it is rather widely used (over 250k licenses in 120+ countries) so it can’t be that bad, can it?

Of course, the value of these foreign currency assets needs to be reflected in the balance sheet in the main currency. That’s the reason there is a main and a second currency, right?

It seems, this needs more exploration from my side. I think I haven’t yet fully grasped how the various accounts tied to party, article, payment, etc. are worked in conjunction during a sale.
I’ll dig further into this and get back here, once I have a clearer picture.

1 Like

I recently found on french accounting rules, that it is possible “on justification”, to record move in foreign currency on some accounts, as long the final balance is presented converted in national currency.

to quote the article 911-1 of PCG_2019:

Art. 911-1
La comptabilité est tenue en monnaie et en langue nationales.
Une opération libellée en une monnaie autre que la monnaie nationale peut être enregistrée sans être convertie si la nature de l’opération et l’activité de l’entité le justifient. Dans ce cas, seul le solde du compte enregistrant ces opérations est converti en monnaie nationale à la date de clôture de l’exercice.

But don’t miss read me: I am not asking for changes. I commented just for completness.