Showing Prices in More Than One Currency on a Tourist Menu

Why tourist venues ask for this

The request almost always comes from the same situation: a venue where a large share of guests are paying in a currency they do not think in, and who are performing mental arithmetic at the table before ordering.

That arithmetic has a cost, and it is not the arithmetic. It is the hesitation. A guest who is unsure whether a dish is expensive orders the thing they recognise, which is usually not the thing with the best margin. In a room where local guests order confidently and visitors order defensively, the average check gap is visible in the till.

So the case for a second currency is real. The case against a bad implementation is stronger, and the difference between them is one decision.

Live rates versus entered prices: what each one commits you to

There are two ways to put a second number on a menu, and they are not variations on a theme.

The last row is the whole argument. A menu is an offer to sell at a stated price. When the stated price is generated from a rate feed, the restaurant has published an offer that no person checked and that will be different tomorrow. If the feed is stale, or wrong, or the pair is thinly traded, that is still your price and still your dispute at the table.

There is a second-order problem too. A live rate makes your menu inconsistent with itself: the printed board says one thing, the digital menu says another, and a guest who saw €11.90 in the window and €12.04 at the table has found an error even though neither number was wrong.

Rounding, and the ugly-number problem

Convert 450 lira at whatever today's rate is and you get something like €10.63. Nobody prices a dish at €10.63.

Menu prices are set with intent — round numbers on a short prestige menu, charm endings in a casual room, consistent steps between tiers so the mid-priced dish looks deliberate. A raw conversion destroys all of that and replaces it with noise. Guests do not know why the menu feels cheap, only that it does.

So round the second currency the way you would round a first one:

• Pick the convention that matches the room and apply it to every item, not per item.
• Round up rather than down when the two currencies drift apart. It absorbs small rate movements instead of quietly eating margin.
• Keep the ordering intact. If the sea bass is above the chicken in one currency, it must be above it in the other — a rounding rule that inverts two dishes has produced a menu that argues with itself.
• Leave a little headroom. A second currency reviewed quarterly should be priced so that a few per cent of movement does not put you underwater.

That last point is the honest trade. Entered prices go slightly stale, and the answer is a margin buffer and a review date, not a rate feed.

Which currencies to offer

The instinct is to add every currency a tourist might carry. Resist it: each one is a full set of prices to maintain, and a maintenance burden nobody keeps up with becomes wrong prices on a live menu.

Two currencies covers most tourist venues — the local one and the one your largest visiting group thinks in. Choose the second from evidence rather than assumption. Your card terminal's settlement reports and the language mix in your own menu data both tell you who is actually in the room, and they often disagree with the received wisdom about who visits.

A third currency needs to justify itself against the cost of keeping it accurate. If it is genuinely warranted, treat it as a full menu to maintain rather than a toggle to switch on.

The same evidence drives the language question, and the two decisions are usually made together — see multilingual restaurant menu.

Displaying two currencies without cluttering the item

There are two workable layouts and one that always goes wrong.

The one that goes wrong is printing both prices beside every dish. On a phone, an item row already carries a name, a description, dietary marks and a price; adding a second price doubles the densest element on the screen and makes the menu look like a currency table.

What works instead:

1. 1A currency switch at the top of the menu, remembered for the session. The guest chooses once and reads a normal menu in their own currency.
2. 2Or a single secondary price, smaller and lighter, on a menu short enough to carry it — a set menu or a wine list, not a forty-item à la carte.

The switch is the better default because it also produces a useful signal: which currency guests actually pick. That is a cheap answer to whether the second currency was worth adding — see qr menu analytics.

Whichever layout you use, keep the currency symbol explicit. "$" alone is ambiguous across at least a dozen currencies, and a guest resolving that ambiguity is doing the work you added the feature to remove.

What to say when the card terminal disagrees

A guest reads €12 on the menu, pays by card, and their bank statement shows €12.40. This will happen, and it is not your menu being wrong.

Three separate things move between the menu and the statement: your entered price, the card scheme's rate on the day, and — where the terminal offers to charge in the guest's home currency — a dynamic currency conversion margin that belongs to the terminal, not to you.

That last one is worth knowing about, because the guest experiences it as your price being dishonest. The staff answer is short and should be agreed in advance: the menu price is charged in the local currency, and choosing to be billed in their own currency at the terminal adds the terminal's own conversion. Declining that offer is usually cheaper for them.

The one thing not to do is describe your second currency as exact. It is a convenience price, set by you and reviewed periodically. Saying so plainly on the menu — a short line under the currency switch — costs nothing and prevents the entire argument.

The same principle governs the words on a tourist menu as the numbers: state what you can stand behind, and do not let a machine publish a claim on your behalf. That case is made in restaurant menu translation.