Hotel Multi-Currency Pricing and Who Pays the FX

Multi-currency pricing means showing, quoting or charging in a currency other than the one your accounts are kept in. It sounds like a single setting and it is really three separate decisions: what the guest sees, what their card is charged, and what lands in your bank. Each can use a different rate, on a different date, set by a different party. Most properties turn on the first without deciding the other two, and a booking engine will happily let them.

The result is rarely a disaster. It is a slow leak, visible only if you compare what you quoted with what you banked, which almost nobody does at the individual booking level. A room sold at 180 in a guest's currency becomes 176 by the time it settles, and the four is written off as a bank charge. This article covers the three currencies, why converted prices look converted, who carries rate movement between booking and stay, what dynamic currency conversion really costs, the disclosure rules that bite the moment you offer a choice, refunds, OTAs, accounting, and what a payments layer should be doing on your behalf.

Every International Booking Has Three Currencies

Separating these three is most of the work. Once they have names, the rest of the article is mostly bookkeeping.

The display currency is what the guest reads while deciding. It has no accounting meaning at all. It exists to stop a Norwegian looking at a price in Indonesian rupiah and closing the tab because they cannot judge whether 3,200,000 is expensive.

The charge currency is what the payment is actually denominated in when it hits the card network. This is the one that appears on the guest's statement and the one that determines who performs the conversion.

The base currency is what your property keeps its books in, files its taxes in, pays its staff in and receives settlement in. It is the currency your folio, your night audit and your profit and loss all speak.

The single most common configuration for an independent hotel is the simplest one, and it is usually right. Display in several currencies, charge in your own, keep your books in your own. The guest's bank does the conversion, the guest pays their bank's spread, and you receive exactly what you expected. You have not made any FX revenue and you have not taken any FX risk.

Every step away from that arrangement should be a deliberate trade, and the trades are what follows.

The Display Currency Is a Marketing Decision

Display conversion exists for one reason: to remove a moment of arithmetic between a guest and a booking. That is a conversion-rate argument, not a finance one, and it should be judged as such.

It matters most where the number is unfamiliar rather than merely foreign. A German reading a price in Swiss francs makes the mental adjustment instantly. The same guest reading Indonesian rupiah, Vietnamese dong or Hungarian forint has to count digits, and counting digits is friction. If a large share of your demand comes from a country whose currency sits at a very different order of magnitude to yours, display conversion earns its place immediately.

It matters least when your market is regional and the currencies are close in scale, which is why plenty of successful city hotels never bother.

The mistake is treating the display currency as a promise. It is an estimate, and every honest booking engine says so somewhere near the switcher, in words to the effect that prices are converted for guidance and the currency actually charged may differ. That sentence is doing real work. It is the difference between a guest who understands they will be billed in euros and a guest who believes they were quoted a fixed price in pounds and will dispute the difference.

Two practical constraints are worth setting from the start. Offer a short list rather than everything, because a switcher with sixty options is a maintenance burden and a support ticket generator, while four or five covering your actual source markets is genuinely useful. And keep the selection sticky across the session, so a guest who switched on the search page is not shown a different currency at checkout, which reads as a bait and switch even when the underlying price never moved.

Converted Prices Look Converted

Here is the detail nobody mentions in the feature list. A price that has been run through an exchange rate looks like a price that has been run through an exchange rate, and guests notice.

Your carefully considered 200 euro rate becomes 171.43 pounds. Your 149 becomes 127.72. The number is correct and it is also obviously machine-made. You have spent real effort on rate structure and psychological price points, and the conversion throws all of it away at the last moment.

There are three ways to handle this and they suit different properties.

Convert and round. Take the converted figure and round it to something plausible, up to the nearest five or ten in the display currency. It keeps maintenance at zero and stops the worst of the machine-made look. Round up rather than down, because rounding down on every rate across a season is a discount you never agreed to.

Set fixed prices per currency. Decide that the room is 200 euros or 175 pounds or 320 dollars, full stop, and maintain those numbers yourself. This is what serious international sellers do. The prices look deliberate because they are, and you are no longer at the mercy of a rate moving your shop window overnight. The cost is maintenance, and the risk is that a sustained currency move leaves one market systematically cheap. Review quarterly, not annually.

Hybrid. Fixed prices in your two or three biggest source-market currencies, live conversion for the long tail. Most properties that think about this at all end up here.

Whichever you choose, resist the temptation to display converted prices to two decimal places when the underlying rate is not that precise. Nothing announces an automated conversion louder than a hotel room priced at 171.43.

Who Carries the Movement Between Booking and Stay

Hotels sell forward. A booking made in October for a stay in June is an eight-month gap between the price being agreed and the money arriving, and exchange rates do not hold still for eight months.

If you display in a foreign currency but charge in your own, none of this is your problem. The guest sees an indicative price in October, and when they are charged in June their bank converts at June's rate. The movement lands on them, they largely expect it, and your revenue is exactly what your rate plan said.

If you actually quote and charge in a foreign currency, you have taken a position. You agreed to accept 900 pounds for a stay in June, and 900 pounds in June may be worth noticeably more or less than it was in October. On one booking this is noise. Across a season, on a market that represents a third of your business, it is a real number that shows up in your performance metrics as unexplained softness in ADR that no one can trace to a rate decision.

Three defences are worth knowing.

Snapshot the rate at booking and hold it. Whatever rate applied when the reservation was created should be stored on the reservation, along with the equivalent value in your base currency. This is not about protecting the guest, it is about being able to answer the question of what you thought this booking was worth when you accepted it. Without the snapshot you cannot tell the difference between a rate that moved and a price that was entered wrongly.

Take a deposit in the charge currency. A deposit converts part of the booking at today's rate rather than leaving the whole exposure open until arrival. It is the cheapest hedge available to a small hotel, and you were probably taking a deposit anyway for the reasons in the deposit policy guide.

Price the buffer in. If you maintain fixed prices in a foreign currency, they should not sit exactly at today's conversion. A modest cushion, one or two percent, absorbs ordinary drift without any guest noticing. This is not sharp practice, it is the same logic that puts a contingency in any forward-priced contract.

What you should not do is chase the rate. A property that adjusts its foreign-currency price list every time the market moves half a percent produces an unstable shop window, annoys returning guests, and spends management time on an exposure that a quarterly review would have handled.

The sharpest version of this problem is not transient at all, and it arrives every autumn. A corporate account or a tour operator asks for a fixed rate in their currency for the whole of next year, which is a twelve-month position taken in a single meeting. Nobody at the table thinks of it as an FX decision, because it is filed under sales.

Two habits make it survivable. Quote in your own currency wherever the client will accept it, since a company with international travel is perfectly used to being billed in the currency of the country it is sending people to. And when the client genuinely needs their own currency, whether because their travel policy demands it or their procurement system cannot handle anything else, put a rate review clause in the agreement: a stated threshold, commonly around five percent movement, at which either side can ask to revisit the number. It is a normal commercial term rather than an unusual one, and asking for it during negotiation costs nothing, whereas discovering in month nine that your best account is now priced eight percent below where you intended costs the whole contract's margin. The wider negotiation is covered in the piece on corporate rates and the RFP season.

Dynamic Currency Conversion Is Not Free Money

Dynamic currency conversion, universally shortened to DCC, is the offer a card terminal makes when it recognises a foreign card: pay in local currency, or pay in your own. It is worth understanding properly because it is the only part of this subject where somebody will actively sell you on it.

The mechanics are straightforward. If the guest chooses your local currency, the transaction goes through in your currency and the guest's own issuer converts it at the issuer's rate, which is typically close to interbank with a small spread. If the guest chooses their home currency, your acquirer performs the conversion instead, at a rate that carries a margin above the interbank mid-market rate. Industry sources put that margin commonly in the range of 3 to 7 percent. A share of it is rebated to the merchant, which is exactly why terminal providers are enthusiastic about it.

So DCC produces a small, real revenue line. On a property doing significant international business it can be a few thousand a year for no additional work.

The case against is not moral, it is commercial. Frequent travellers know what DCC is and decline it, so the guests most likely to accept are the least experienced, and the ones most likely to look at their statement later and feel taken advantage of. The spread is disclosed but it is disclosed at the moment somebody wants to finish checking out, which is not when people read carefully. And your staff end up in the middle, because the terminal asks a question the guest does not understand and then looks at the receptionist for guidance.

If you offer it, three rules keep it clean. Train the desk to present it as a neutral question rather than a recommendation, because a receptionist saying “just press the pound one, it is easier” is doing something the card schemes explicitly prohibit. Never let it be selected on the guest's behalf. And be able to explain the number if asked, which means somebody in the building needs to know what the margin actually is.

What the Rules Require the Moment You Offer a Choice

The instant you present a currency choice you are inside a regulated interaction, and the obligations are more specific than most hoteliers realise.

Card scheme rules are the first layer. Mastercard's merchant guidance on DCC is explicit that the offer must not be presented as the default, that the cardholder must not be required or encouraged to use it, that the offer must be clear and neutral, and that the cardholder's choice must be respected. That last point comes with a worked example that is, of all the possible examples, a hotel: a property that asks a guest to tick their currency preference on an advice slip and then performs a back-office conversion in the other currency anyway. That is a rules violation, not a clerical error, and it is common enough to be named.

The second layer, for anyone taking cards in the European Union, is Regulation (EU) 2019/518, which amended the cross-border payments regulation and has applied since 19 April 2020. It requires that total currency conversion charges for card-based payments be expressed as a percentage mark-up over the latest available euro reference rates published by the European Central Bank, and that this mark-up be disclosed to the payer before the payment is initiated. The intent was to make competing conversion offers comparable, since a raw exchange rate tells a traveller nothing about whether it is a good one.

The practical consequence for a hotel is short. A currency choice at the terminal or in the checkout has to show both amounts, the rate applied, and the margin over the reference rate, before the guest confirms. If your terminal does not display that, the gap is your acquirer's to fix, and it is a reasonable thing to ask them about at renewal.

One related point that catches properties out. A guest who was charged in a currency they did not choose has strong grounds for a dispute, and disputes over currency are unusually winnable for the cardholder because the evidence is on the receipt. Keeping the choice clean is chargeback prevention as much as compliance, which is the same argument made at more length in the chargeback guide.

Refunds Are Where FX Actually Hurts

Everything above concerns money coming in, where the amounts are agreed in advance and everyone is in a good mood. Refunds are the opposite, and they are where currency handling produces genuine complaints.

The problem is that a refund happens on a different date to the payment, and a foreign-currency amount converted on two different dates produces two different numbers. A guest who paid 500 in their currency and receives 493 back has, from their point of view, been charged seven for the privilege of cancelling.

The rule that avoids most of this is simple: refund the original transaction rather than creating a new one. A true refund against the original authorisation reverses the same amount in the same currency, and the card scheme handles it as a reversal rather than a fresh conversion. Issuing a refund as a new payment in the opposite direction, which is what happens when somebody processes it manually from a terminal, guarantees a mismatch.

Even with a proper reversal the guest may see a small difference, because their own issuer converted on the way out and converts again on the way back, on two different days. That is outside your control and it is worth having a one-sentence explanation ready rather than arguing about it.

Partial refunds deserve their own care. If you refund one night of a three-night foreign-currency stay, refund the proportional amount of the original transaction rather than recalculating one night at today's rate. The two figures will differ, and only one of them is defensible on a receipt.

Where this collides most often with real operations is cancellation terms. A policy expressed as a percentage refund is currency-neutral and survives all of this comfortably. A policy expressed as a fixed fee in your local currency becomes, for a foreign guest, a fee that changes size depending on the day. Neither is wrong, but the second one needs a sentence in the terms so it is not a surprise. The wider mechanics are in the cancellation policy guide.

OTAs Quietly Add a Fourth Currency

Just as the three-currency model starts to feel manageable, distribution introduces another one.

An OTA takes your rate in the currency you loaded, shows it to a traveller in whatever currency that traveller is browsing in, and then pays you in the currency of your contract, which may be neither. If the booking is one the OTA collects payment for, there is a conversion inside the platform that you never see and cannot audit. If it is a booking you charge yourself, you are back to your own arrangements, but the guest has already seen a number on the OTA that you did not calculate.

Three consequences are worth naming.

Commission is charged on their number, not yours. A commission percentage applied to a converted amount, then paid out to you after another conversion, is not the same as the percentage applied to your loaded rate. It is usually close. It is not always close, and the difference belongs in the same arithmetic as the rest of your net ADR after commission.

Rate parity comparisons get muddy. Somebody comparing your direct price with an OTA price in a third currency is comparing two conversions, not two prices. Before concluding that a channel is undercutting you, check whether the gap is a discount or a rate. The rules that actually apply to parity in the EU are covered in the rate parity guide.

Payouts arrive net of a spread you did not agree. If your contract pays you in a currency other than your base, the platform converts on its own terms. Where volume justifies it, holding a local account in the payout currency and converting yourself is meaningfully cheaper, and it is an ordinary request rather than an exotic one.

None of this is a reason to avoid selling internationally. It is a reason to compare channels on what lands in your account rather than on the rate you loaded, which is a good habit for all the reasons in the piece on reducing OTA commission.

One Base Currency, Many Quotes

The accounting principle underneath all of this is worth stating plainly, because it resolves most arguments about how a system should behave.

A property has one base currency. Everything that happens in the building is ultimately expressed in it: the folio, the night audit, the daily revenue report, the profit and loss, the tax return. Quotes can be in anything you like. The books cannot.

That means every foreign-currency transaction needs two values recorded, the amount in the transaction currency and the equivalent in base, along with the rate used and the date it applied. Store the rate, not just the result. A converted figure with no rate attached cannot be checked, and the first time an auditor or an owner asks how a number was arrived at, you will want the rate.

Where properties get into trouble is running the folio itself in multiple currencies. It sounds like the natural next step and it creates problems out of proportion to the benefit. A folio with charges in two currencies has no single balance, so the guest cannot be told what they owe in one sentence. Reporting either picks a rate for the period and restates everything, or produces totals that do not mean anything. And any difference between the rate at posting and the rate at settlement has to be recognised somewhere, which is a real accounting entry rather than a rounding tolerance.

The pragmatic arrangement, and the one most hotel systems settle on, is a base-currency folio with the foreign amount carried alongside for reference. The guest gets one balance. Reporting gets one currency. The quote currency is preserved on the reservation so you can always show what was agreed. Invoicing can then be produced in another currency when a corporate client or a tour operator requires it, which is a presentation step at the end rather than a change to how the ledger works. The night audit implications of getting this wrong are covered in the hotel accounting playbook, and if any of the terminology here is unfamiliar, the terminology glossary defines it.

Foreign Cash at the Front Desk

Accepting euros in a country that does not use them was once ordinary hotel practice and has quietly disappeared from most properties. The reasons are worth restating, because the question comes up every season from a well-meaning general manager.

The rate is the first problem. To accept foreign notes safely you have to quote a rate poor enough to cover a day or two of movement plus the cost of getting the notes banked, and the rate that protects you is bad enough that a guest who checks it later feels cheated. You are running a small bureau de change with none of the volume that makes one work.

Banking is the second. Many banks now charge meaningfully to accept foreign notes, some will not take coins at all, and the trip to deposit them is somebody's afternoon.

Counterfeit risk is the third, and it is the one people underestimate. Your team can spot a fake note in the local currency because they handle them daily. Nobody at the desk can reliably assess an unfamiliar foreign note at eleven at night.

The sensible modern answer is to accept cards for anything that is not local cash, which is what nearly every property has converged on. If you are in a destination where foreign cash genuinely still circulates, set one published rate, review it weekly, accept notes only, and make it clear at the desk what the rate is before the guest hands anything over. Whatever you do, the till is a base-currency instrument, and pretending otherwise creates a reconciliation problem at every shift change. The related discipline for the till is in the hotel POS guide.

Groups Trading Across Two Currencies

For anyone running properties in more than one country, one decision causes more downstream pain than the rest combined: whether each property keeps its own base currency.

It should. A hotel in Spain files Spanish tax, pays Spanish staff, buys from Spanish suppliers and holds a Spanish bank account. Its books belong in euros regardless of where the owner is. Forcing a property onto a group currency because head office reports in dollars means every local number is a converted number, every local reconciliation carries a rounding difference, and the general manager cannot check their own P&L against their own bank statement.

Consolidation is a reporting problem and it belongs in the reporting layer, where you can apply a stated rate for a stated period and label it as such. Whether you use the closing rate, an average for the period, or a budget rate set once a year is a decision for whoever owns the group accounts, and the only thing that matters operationally is that the rate is documented and consistent between periods. A portfolio report that silently changes its conversion basis is worse than no portfolio report.

The same logic applies to intercompany charges, management fees and shared costs allocated across borders. They are real transactions in two currencies and they need a rate and a date, not a spreadsheet formula that quietly picks up today's number every time somebody opens the file.

What Your PMS Should Be Doing Here

Most of the failures above are software failures wearing an operational costume. A system that handles currency properly makes the right behaviour the easy one, and the requirements are specific enough to check against a demo.

It should hold one base currency per property, set deliberately and not casually changeable. Changing an accounting currency after transactions exist is not a settings edit, it is a migration, and a system that lets somebody do it from a dropdown on a Tuesday afternoon is being unhelpful.

It should let you nominate which additional currencies you actually support, rather than treating every ISO code as equally live. Every currency you enable is a price list somebody has to maintain and a support question somebody has to answer.

It should let you choose between maintained rates and automatic ones, with a refresh interval you control, and it should let you pin a rate manually when you need to. Pinning matters more than it sounds. It is what you use when a currency is moving sharply and you would rather hold a known number for a fortnight than track the market.

It should let you set a fixed price per currency on a rate plan, an item and an add-on, and use that fixed price in preference to converting. This is the feature that separates a system designed for international selling from one that has a conversion function bolted on.

It should record, on the reservation itself, which currency was quoted, the rate that applied and the base-currency equivalent, and it should stop that currency changing once the booking has content. A quote currency that can be switched halfway through building a reservation produces a booking where half the lines were priced on one basis and half on another.

And it should keep the folio in one currency while preserving the quote, so the guest can be told a single balance and the accounts stay coherent.

Prostay implements this at property level under system settings, and it is worth walking through because it shows what that checklist looks like in practice. Each property has an application currency, which is the accounting currency for that property, and it locks once set, so a group can run a euro property and a rupiah property side by side without either pretending to be the other. Multi-currency is then enabled per property, with an explicit list of the additional currencies you support rather than an open field.

Rates are held as the value of one unit of a foreign currency in your base, which is the direction that stops the classic inverted-rate mistake. You choose whether they are maintained by hand or refreshed automatically on an interval, and you can pin an individual currency so that a manual rate overrides the automatic one for that currency only. Rate plans, items and add-ons can each carry fixed prices per currency, and where a fixed price exists it is used instead of a conversion.

On a reservation, staff pick the quote currency before searching for rooms, and it locks once rooms are added. The booking then stores the quote currency, the exchange rate that applied, the base currency and the base equivalents, and the screen shows the folio equivalent alongside the foreign quote so nobody has to trust a mental conversion. On the guest side, the booking engine can offer a currency switcher with a plain statement that prices are converted for guidance and the currency charged may differ.

Two things it deliberately does not do, and both are the right call. The folio, the till and the payment records stay in the property's base currency, so there is always one balance and one set of numbers in reports. And when an invoice is needed in another currency, it is produced as a presentation step, prompting for any prices that are missing in that currency, rather than by restating the ledger. There is no FX spread applied on top of your rates either, which means the rate you configure is the rate your guest sees.

A Setup That Works for Most Properties

If you are starting from nothing, this configuration covers the large majority of independent hotels and takes an afternoon.

Set your base currency to the currency of the country the property is in. Not the owner's currency, not the currency your investors think in. The building's.

Charge in that base currency by default. The guest's bank converts, the guest pays their own bank's spread, and you receive what you expected. This single decision removes almost all FX risk from your operation.

Enable display conversion for the three or four currencies your actual source markets use. Check your arrivals by country of residence rather than guessing, because the answer is often not what the sales team assumes.

Set fixed prices in your one or two biggest foreign markets, and let the rest convert. Round the converted ones so they do not look automated.

Refresh rates daily rather than continuously. Hotel prices do not need to move with the market, and a stable shop window is worth more than a precise one.

Take a deposit on foreign-currency bookings with long lead times. It converts part of the exposure early and it is good practice anyway.

Decide your position on DCC, write it down in one sentence, and train the desk to it. Either you offer it neutrally or you do not offer it. What you cannot have is each receptionist deciding on their own.

Review the fixed prices quarterly against the market rate. Twenty minutes, four times a year, catches the sustained move that would otherwise leave a whole market mispriced for a season.

The pattern underneath all of it is that FX cost never disappears; it only moves. Every arrangement in this article decides who carries it, and the ones that feel free are the ones where a guest is carrying more than they realise. Being deliberate about that is not just cleaner accounting. It is the difference between a guest who books again and one who reads their statement, works out what happened, and quietly does not.