Multi-Currency Journal Entries - The Techie Side? Transaction # 1

Lets look at the tech behind Multi-currency accounts. In order to do this we have to make two assumptions:

1) An ERP or management system that maintains all day to day transactions

2) An application that creates the transactions (customer end).

Lets say we have a customer who wants to pay for a visit to a hospital while aboard. Assume that the transaction is 10,000 CAD and they permanently reside in the UK (i.e., they will pay in GBP).

They will go into the application (our web app) and select the Hospital and the country they are paying from, in this case we will say the hospital is North York General. Now having selected their country as UK, they will be given a few options.

1) Wire Transfer in GBP

2) BACS - with a 30 GBP fee + FX

3) Visa / MC - 5% charge

We will get into the concept of Pricing Strategy later, however, assume Wire Transfer in GBP is the cheapest.

The customer will receive a quote from us expecting 5,450 GBP. Note, this will not include outgoing wire charges from their Beneficiary Bank. Once they agree, they will lock in the rate and be given 48 hours to remit funds. To lock in the rate, they will need to fill out a KYC form which include Beneficiary Name and Address, along with uploading a Passport or Drivers License.

Once funds are received in our bank, we will then push the transaction into our ERP system via API. The client name would be the Hospital and the Payment information would include the payment currency, the amount received, and the amount to be converted which is locked to $10,000 CAD. The reason we put the amount received rather than the transaction amount of 5,450 GBP is because (1) that matches our bank for reconciliation and (2) it nets off any fees from the beneficiary bank or other intermediary banks. Hence, pricing strategy dictates, those are baked into the client’s prices, along with the FX rate.

In the notes of the transaction we add a comment indicating the name of the beneficiary and the transaction number from the web app.

The Hospital Name which is pushed is not necessarily value in text format. What actually happens is upon onboarding the customer is created in the ERP and given an ID. Similarly the Hospital is also created in the web app and given a separate ID. A database table is used to connect the two IDs. When the customer selects the hospital at the beginning of the process, the web app ID is selected. When the transaction is pushed into the ERP further downstream, the API picks up the ERP ID stored in the web app.

The Payment Option is selected as Wire in the API and the Internal Transfer Settlement type is also selected in the API. These are stored in a separate DB table in the web app. The Internal Transfer Account for the hospital is stored with the ERP ID in the web app. The payment options are stored in a payment options table linking the ERP ID and Web App ID. Depending on step in the process, and the currency received, different permutations of payment and settlement types are selected. Look at the Excel in previous blog posts for more guidance on this.

If a transaction fails when the API pushes data, an error log returns. In most cases, a currency is not defined (if very obscure) or there is a network connectivity error.