6

Having one e-commerce system for multiple markets. Having markets related 1:1 to currencies.

Having one database storing all order information (cost, price, invoicing)

How to manage different currencies?

  • normalise all saved data to one single currency (and at display time apply conversion rate)?

  • save everything in the actual currency (price,currency_id, conversion_value) ? (and actual conversion value to a baseline currency, for post analysis purposes)?

  • or better go for different data business units for every values.

Points to consider are no just e-commerce complexity itself in order to manage currencies, but also data post analysis, is it more convenient to have a global analysis comparing against a single currency(normalised) or having differentiate analysis per currency?

koalaok
  • 493
  • 5
  • 17
  • 4
    When a purchase is made, it might be best to store the currency that the customer chose for their purchase, and the exchange rate *at the time of that purchase*. You can then use that information to normalize to a single currency for data analysis, if you need to. But I've never done this myself so I'm not sure I should actually leave that as an answer... – FrustratedWithFormsDesigner Mar 21 '17 at 14:45
  • 1
    I think an accountant would give you a better idea. – JeffO Mar 21 '17 at 15:04
  • Which country is the home country for this application? – Robert Harvey Mar 21 '17 at 15:14
  • many countries... could be uk £, germany €, USA $ – koalaok Mar 21 '17 at 15:42
  • Why do you want all currencies and markets served by the same database? It seems like an unnecessarily restrictive design for data that naturally partitions itself so well. Also, you want to know the actual amount you received, not transform it into something else unless you are actually exchanging the money at that point. – TZHX Mar 21 '17 at 18:43
  • 1
    Each product needs to have a price in the markets that are supported. Then you will not have floating prices. Users see the same price unless you adjust the price, not the money market adjustments based on currency exchange rates. – Jon Raynor Mar 21 '17 at 20:16
  • How does the non-e commerce side of the business want to handle it? What happens if someone rings up on the phone and says "hello, I'd like 1000 of Product X and I'd like to pay in Thai baht"? – user253751 Jul 02 '20 at 15:00

3 Answers3

5

Don't do conversions on my money and hide it from me!

When I sit down to order something that says it's $9.95 it had better give me back $9.95 when I return it.

If I'm ordering something that says it's in some goofy currency that I don't normally use then I'll deal with the conversion rates. At least I know I'm dealing with conversion rates. I won't know that if you don't record what I actually paid you.

So no. Don't be normalizing all data to one single currency. Each market sets it's own prices in it's own currencies. Here's why:

$9.95 is a price set by people trying to hide the fact that it's about $10. The 5 cents isn't because of some exchange rate. It's because someone decided that price looked good. You can't go messing with that because the yen is trending down.

Think about this the same way you think about storing someones age. We don't store how old you are. We store your birthday and do the math when we report your age. For the same reason you shouldn't store that I paid the equivalent of twelve pieces-of-eight when I bought my car. You should store how much of whatever currency I paid. If you also want to jot down whatever some exchange rate happened to be at the time for whatever reason fine but that's nothing to do with me.

There are many reasons it's important to record what actually happened rather than what you plan to report. But one thing that strikes me about this is if you don't record what really happened you can end up being a de facto currency exchange. Maybe you need that but that should be a completely different system.

candied_orange
  • 102,279
  • 24
  • 197
  • 315
3

How to manage foreign currencies accros the sales process ?

The purchase orders in your system are made in a "market currency", i.e. the contractual currency, which is the base for defining the contractual obligations.

Therefore, every purchase order must be stored in its market currency: this is the real base to invoice the customer, whatever the currency fluctuations could be.

When you invoice the customer, you still need to keep track of the amount in market currency. At the same time, you have the obligation to maintain all your accounts in the company's currency. So you need to keep track of the value in the company's currency as well.

Practical example

Imagine a European company that manages its account in EUR. Imagine that this company sells goods in USA, via an online shop in which the prices are displayed in USD. The customer places an order for an item: 

Order   100 USD (market price)
        at the time of the order this is worth 80 EUR (company currency).

1 week later, the company delivers the goods and invoice the customer. 

Invoice 100 USD (agreed market price) 
        at the time of the invoice, this is worth 75 EUR due to an increase of the euro (company currency)

In the accounts of the company, the revenue is 75 EUR, and this is the amount that the company has to care of for local tax issues and legal reporting. So the best is to store it as well (with or without the exchange rate).

3 weeks later, the customer makes a bank transfer. Of course, he'll pay the amount owed in USD. He doesn't care about EUR: 

Payment:  100 USD (market and invoice price)
          at the time of the payment, this is worth 85 EUR due to a decrease of the euro

So in the customer accounts, you know that the customer owes 100 USD - 100 USD = 0 USD. So you the transaction is finished: you do no longer expect anything from the customer.

In the same time, in the company's currency, you've registered first a debt valued 75 EUR, and a payment valued 85. So in fact, you earned 10 EUR more than expected when you booked the invoice. These 10 EUR will then be posted as "currency exchange gains", so that the balance is also 0 in company's currency.

Both currencies ? Or one currency and a conversion rate ?

All the amounts must be protected against any rounding difference that could occur when using exchange rates. Unfortunately, if you have a more complex purchase order with several products, there could be rounding differences if you add the converted item price and if you convert the total amount of the order. To avoid issues with such rounding difference, the best is to store the value simultaneously in each currency.

Christophe
  • 74,672
  • 10
  • 115
  • 187
1

Both methods are valid in certain situations. For example, when i use my credit card abroad in an ATM the ATM will offer to charge me in my local currency at an exchange rate.

However, The key question in an e-commerce website scenario is, 'What currency bank accounts does the owner of the store have?'

A small company can probably only accept their local currency. They are unable to accept a payment in other currencies, but the purchaser's bank will happily allow them to pay in any currency, charging them the appropriate fee and exchange rate. So the small company can just show the price in the local currency and leave the exchange rate to the customer.

A large company may well operate across multiple markets and have bank accounts in the correct currency for that market. However they will price thier goods separately in each market regardless of the exchange rate.

Also they will hold cash and pay tax and hence want to report, in those currencies.

The only scenario where you want to offer an exchange rate is if you are a money changer or bank or perhaps a third party payment provider/marketplace like ebay

Ewan
  • 70,664
  • 5
  • 76
  • 161