Secondary currency on invoices

Idea.
I would like to see a feature of being able to automatically display a secondary currency on an invoice which is required in several countries.
When issuing an invoice in a currency that is not the local currency in a country like United Arab Emirates then we need to mention the equivalent amount in the local currency with the currency exchange rate of the day, ideally just below the foreign currency total amount.
We have until now used a template for that but when the currency exchange rate changes then we need to change the template every time.
Please consider adding this feature for us.

You can enter the exchange rate in a custom field without using a custom theme.

True, but wouldn’t that require an entry per item? I think it is much better to offer this option in the system and secure all invoices to be according to the exchange rates of Manager.
One thing in regards to custom themes is that there is no way to format the output number…
USDAED

No. Just as you have shown in your screen shot (which I presume is from your custom theme), you would enter it once. Custom fields are normally shown just below the totals section, unless you place them elsewhere using a custom theme.

The program already offers it. That is what custom fields are intended to provide—special needs for specific circumstances. Most countries do not require what you want.

That is up to you and how you program a theme. Using a custom field, you can specify text and enter whatever you want.

That is not correct, I would say MOST countries do indeed require this.

A short summary:

Must show equivalent amount on Invoice:
UK https://www.gov.uk/guidance/foreign-currency-transactions-vat-and-tour-operators
Iceland https://www.avalara.com/vatlive/en/country-guides/europe/iceland/icelandic-invoice-rules.html
Poland: https://www.avalara.com/vatlive/en/country-guides/europe/poland/polish-vat-invoice-requirements.html
United Arab Emirates: https://www.tax.gov.ae/pdf/Cabinet-Decision-52-of-2017.pdf

Must show only the used exchange rate:
European Union: https://www.avalara.com/vatlive/en/eu-vat-rules/eu-vat-returns/invoice-requirements-eu-vat.html

I think we have to agree to disagree. I prefer automatic calculations where possible in order to minimize the room for human errors.

@Leifur
you can enter the exchange rate in a custom field and make the theme display the equivalent amount. read the below guide for ideas.
https://www.manager.io/guides/17115

1 Like

I am well aware of the custom field and calculations etc but I find that solution unsatisfactory.
What happens if the currency exchange changes from day to day… you enter the exchange rate for the custom field manually every day (per each invoice even!) and then how is that represented in the booking system? It is just a display dummy for the invoices etc and is not recorded in the system, which means it could allow errors in VAT returns for countries that have different base currency than the invoice currency.
This is a serious matter that I hope @lubos will take seriously into consideration to implement it…
Now, to the issue of formatting the manually calculated number… does ANYONE have a format solution that puts a value to xx,xxx.xx format? I have only been able to get xxxxx.xx without the thousand and million seperator… as seen on my example above…

It is stored as the content of the custom field where you entered it. It will not affect any accounting information entered unless you write a custom theme that includes calculations with custom fields. You need to explain and illustrate your concern about VAT returns. Conversions to base currency are unrelated in the program to custom field content. So it is not clear what you are worried about.

Yes, the program has this built in. If you create a custom field of number type, its format responds to changes of your number format preference. And, as I said before, if you select a text-type custom field, you can enter anything you want into it.

  1. When custom field is used, no info is affecting the stored VAT.
    This means when I invoice 1000 USD to a company abroad with 10% VAT included, the VAT should be 100 USD (simplified example). But since my accounting system us set to AED currency with a dummy exchange rate of the day to be 5 AED per 1 USD, the system would put the equivalent of 100 USD into the VAT account but the conversion is based on the exchange rate set in the system and NOT the one entered in a custom field for example. Then I am invoicing an amount to a client and I am not returning the same equivalent amount to the authorities which is a serious offence in most countries if not all… Therefore it is ESSENTIAL that this is implemented the soonest.
    Bottom line: Dual currency invoices need the exchange rate of the day to be fixed and used in the invoice issued that day and all the derived calculations need to be professionally stored and documented in the Manager system. The displayed values and the stored values must always be the same… That can only be achieved with an integrated currency exchange system… No other way.

  2. That is not working. First of all, in order to display any calculated value on an invoice then you need the custom field option “Show custom field on printed documents” to be enabled. It can’t be hidden if you want to use it for any calculations. Secondly, if you format the number in the custom field to “3.6725” then the calculated value is still on the format “xxxxxxx.xx” and there is no way to display a calculated value with the thousands seperator. I urge you to try it yourself before replying and saying that you can. I have tried everything!

The displayed summary below is the results from a formatted currency value but the answer does not reflect the formatting, contradicting your answer that the calculated value would inherit the formatting of the custom field… (I made the XE value in thousands in the below example in order to try to get it formatted with thousands seperator…)

{{ "Equivalent Amount in AED (Exchange rate: 3.6725)" }} {{ table.totals["Total"] | times: custom_fields["XE"] | round: 2 }} ![Manager|690x89](upload://am9fhynmQgKCz5Z3bYMRgJCRDQ6.png)

I did not say that, @Leifur. I said that number-type custom fields respond to changes of your number format preference. Your posts have been a little hard to follow, because you seem to switch from discussing custom fields to custom themes quite frequently. They are not the same. My comment was addressing the behavior of custom fields. You now seem to be focusing on behavior of calculation results, which can only be accomplished with custom themes. Performance of custom themes is the responsibility of the user. I told you that in post #4.

Also, if I understand your complaint about exchange rates, you must realize that tax codes apply percentages to amounts, saving the results in your base currency in Tax payable. Tax charged to the customer is only presented in the customer’s currency on the invoice, for Accounts receivable. The Tax payable account is only valued in your base currency, so what you seem to be expecting to happen will not.

Then change the exchange rate set in the system to match the one entered in the custom field.

The exchange rate set in the system can be changed daily - if required - by “adding” a new exchange rate with the applicable date, not by editing an existing exchange rate.

However, you can’t have multiple exchange rates for the same day.

But the question is this, why are you using an exchange rate on the invoice which is different from the system exchange rate, surely the rate doesn’t fluctuate that much and tax authorities tolerate an approximate exchange rate without it being that precise.

E.g. - some users set the system exchange rate to be a mid-rate for a period (month, quarter, year) and then review it as required.

Thank you for your replies Tut.
Yes, I agree that my posts can be hard to follow, I do not know how you can import a part of a message and reply only to that one in a single reply, once I learn that then I believe it will be easier to follow my replies etc. My apologies.

Custom fields:
I understand now that your solution of using a custom field for this purpose is just to have a text box that I can put anything into and it will be reflected on the invoice.
This is clear, but not an acceptable solution.

Custom theme:
I have solved this issue temporarily via custom theme. The results are working for me but the formatting of the amount is not perfect. It is displayed in xxxxxxx.xx format but I would like it to be formatted with a thousand and million separator. This is normally possible with “number” setting in the script language but it doesn’t work in Manager’s version of it.
The script uses a fixed number as the exchange rate since I am not able to extract the exchange rate from the system. This means I need to create a new theme for each update of the exchange rate. Luckily my system currency (AED) is pegged to the USD which is my main business currency. This theme solution wouldn’t work otherwise.

It is very easy programming for @lubos to add the option on invoices (and other forms if you like) to display a second currency value. This would for sure be helpful for many of Manager’s users, not only me.

Thank you for your reply Brucanna.

Yes, you are right. It is possible to add exchange rates daily and not modifying the previous ones.
If I do that then there is a value of tax added to the tax account and all is fine, based on Manager’s calculations using the exchange rate set in the system. We can agree on that as a final answer to my worries of which tax amount is saved in the system.

If I make an error or if there is any discrepancy between the system tax amount and the calculated tax amount on each invoice (using the displayed exchange rate) then we have a great issue.

I simply feel uncomfortable using a manual field or calculation when issuing my invoices. I want to set the exchange rate of the day into the system and then work on my invoices etc without having to manually enter the exchange rate of the day onto each and every invoice I issue etc. and display the AED equivalent sum amount below the USD final sum amount, with the exchange rate as well.