We have employees in US and UK. And corporate AMEX cards for all employees, regardless of the office location or local currency, gets paid in USD.
For a UK based employee, we defined GBP as the reimbursement currency. Problem is all AMEX charges only come in as GBP and not GBP and USD.
I've googled this question and also reached out to my implementation coach, but the response I received is to create separate log in IDs for non_US employees; one for reimbursement currrency of, say GBP for a London based employee for cash/OOP expense, and another one for USD for AMEX payments. We would rather not do that as we use corporate email as the log in ID.
I've learned that while Cash/OOP payment type lets you change currency, auto-fed credit card charges do not let users to change the currency. I was thinking about setting USD as the reimbursement currency for all employees, both US based and not, and have users to manually override USD to local currency on Cash expenses.
Have you ran into this scenario?
Do you have any suggestions?
Thanks for your input.
Thanks for posting!
This might be a good question for our User Admin Group. Are you your company's Admin? If so, you should check it out! Our User Admin Group members have access to the peer-to-peer knowledge sharing of the group as well as the "what's New in Product" blog where we share the latest updates right from our product teams.
Hope this helps!
First, I want to say that the ideal solution for the long term is to make sure each user has an AMEX card with a posting currency that matches their reimbursement currency. This will resolve these types of issues. However, there may be any number of reasons that this is not an option for you and if it is not, we do have a possible solution. We call it Currency Triangulation.
There is a specific field in the Standard Accounting Extract (SAE) called Billing Amount (column 153) that can be used to help pay these cards. The Billing Amount filed is the Journal/Posting Amount converted to the currency of the card (USD). You can use this field to determine how much USD you need to pay down on the GBP user's cards.
Thank you for your response. I just reviewed the extract and that field is shown as NULL. However I did notice that Concur extract contains details provided by AMEX, here both GBP and USD amounts. Problem is that these details are only available on the extract after it's been sent for payment and not on the UI while in the approval process. Thank you.
|Credit Card Transaction Amount||Credit Card Transaction Tax Amount||Credit Card Transaction Currency Alpha Code||Credit Card Transaction Posted Amount||Credit Card Transaction Posted Currency Alpha Code||Exchange Rate From Billing To Employee Currency||Billing Amount|
I know this is an old post, but wondering if you ever received resolution? We are working on a change to our interface to pull in the "billing" currency for the credit card transactions, however, where we are running into an issue is the VAT amount in the "billing" currency. It appears the AP / GL Extract sends the VAT in the "spend" currency and "reimbursement" currency, but not in the "billing" currency which is what we need to process the transactions appropriately in our Finance system. If you found a resolution, would like to understand what it was.
@leela2516 will the solution provided by GrantC in this thread not work for you?
@KevinD - It did solve part of the problem, but where I have an issue now is that the VAT amount is not provided in the "billing" currency. The AP/GL extract only provides the VAT amount in the transaction and reimbursement currencies - so although the charge is "triangulated" the VAT is not. As we post the VAT to a different account than the expense, we are probably going to have to see if we can calculate the VAT and the expense portion in the "billing" currency using our interface coding. Not an ideal situation, but if we want to implement our GDC countries (we have 8 targeted), then we have to figure out some solution. I did open a case and they have confirmed the VAT amount is not provided in the "billing" currency, only in the transaction and reimbursement currencies. Any thoughts on a better solution?