Multi-Currency Display: What the Guest Sees and What You Keep

The number on the listing and the number in your account are two different figures, and the gap is not an error.

Last updated: October 24, 2026

A guest browsing from another country sees a price in their own currency. You set that price in yours, and you get paid in yours too. Between those three moments the number changes at least twice, and neither change happens when you edited the rate. That's why a payout can look wrong while every calculation behind it is correct: you're comparing two figures that were never meant to be equal.

Key Takeaways

• One booking, at least two figures. The guest's display price, the amount charged, and your payout can all be in different currencies.
• The conversion has a place. It happens at a point set by the channel and the payment path — not when you set the rate.
• Your payout lands on a different date. The rate applied depends on the channel and the payout date, which is why the gap moves month to month.
• The gap is timing and spread, not an error. Until you can name which of the two it is, you can't fix anything.
• Reconcile on the payout date. Convert each payout at the rate it was actually paid at, and keep one line per payout.

Two prices, one booking

Start with what the guest sees. A rate plan holds a price, and the display layer shows it in whatever currency the visitor's session is set to. That's a presentation decision, and it's the one most hosts think about, because it's the one on the screen.

Then the charge. The guest's card is debited in a currency determined by the payment path, which isn't always the currency they were browsing in. A guest who switched the page to their own currency may still be charged in the property's currency, or in a third one the channel settles in. The screen doesn't promise otherwise, and the confirmation usually says which.

Then your payout. It arrives in your account currency, on the channel's schedule, which can be days or weeks after the stay. Three figures, three moments, and only one of them is under your direct control.

The mistake to avoid is treating the first figure as the truth and the third as a deviation. They answer different questions. The first answers "what did this cost the guest". The third answers "what did I keep". Both are correct.

This is also why screenshots mislead. A guest's screenshot of a price and your payout line can both be accurate and still not match. A host who assumes one of them must be wrong spends an afternoon on arithmetic that was never going to resolve.

Where the conversion happens

There are three plausible points, and which one applies depends on the channel and the payment path.

At display. The listing is converted for browsing. This figure is indicative and is usually refreshed on a schedule, so it can be a little stale by the time somebody books.

At booking. The amount is fixed in whichever currency the payment is taken in. This is the figure that matters for what the guest was charged, and it's the one to quote if a guest asks.

At payout. The channel settles to you in your currency at a rate it applies on the settlement date. This is the figure that reaches your account, and it's the only one that affects your cash.

There's a fourth conversion you don't control at all: the guest's own bank, on their side of the transaction. If a guest says they were charged more than the page showed, that's often where the difference sits, and it isn't yours to explain beyond pointing at it.

Which point applies, and whether more than one applies to a single booking, depends on the channel and the payout date. Check the current terms on the channel rather than assuming the mechanism is the same everywhere — it isn't, and it has changed over time.

The practical consequence is that you can't reason from the display price to the payout. You can only reason from the payout to the payout.

What lands in your payout

The payout line is a converted figure, and it's converted from a base that's already been reduced. Two things have happened before it reaches you: the channel took what it takes, and a conversion was applied to what remained.

That order matters more than it looks. A conversion applied after deductions converts less money, and a conversion applied before converts more and then deducts in your currency. Both are defensible, both appear in the market, and they produce different numbers from the same booking. It's one reason two hosts on two channels can compare headline rates forever and never agree on net.

Then the date. A rate applied on a Tuesday isn't the rate applied on the Friday payout. Small movements across a week are normal rather than suspicious. Because the rate depends on the channel and the payout date, a gap that appears in one month may vanish in the next without anything having been fixed.

What you can control is smaller than it feels. You can set the price, choose which currency the plan is listed in, and decide how much of the FX exposure you're willing to absorb rather than pass on. You can't set the rate that will apply on settlement, and you shouldn't price as if you could.

What you can also do is stop comparing the wrong pair. The payout isn't meant to equal the listing price. It's meant to equal the listing price, minus deductions, converted at settlement. Reconstruct that chain and the number usually explains itself.

Reconciling a month

Reconcile per payout, not per booking and not per total. For each payout, record four things: the date it landed, the amount in your currency, the amount in the booking currency if the channel reports it, and the rate implied between them. Four fields, one line each.

Convert at the payout rate, never at today's. A month-end total built from today's rate will disagree with your bank statement every time, and the disagreement will look like an error rather than a method.

Don't sum across currencies before converting. Two payouts in two currencies added as raw numbers produce a figure that means nothing, and it's the most common way a monthly total goes wrong.

Then compare quarters, not days. Daily noise is the mechanism working; a quarterly drift is a pricing question. If the drift is consistently against you, the answer is usually in the rate, not in the conversion.

Finally, keep the log somewhere you'll look at it again. One page per month, four fields per payout, and a note of anything unusual: a refund, a chargeback, a stay that crossed a month boundary. That page is what turns a confusing payout into a predictable one, and it's what lets you answer a guest's question about a charge without guessing.

The rate plans view on localsbnb.com shows nightly rates with their currency. Each connected channel's source rate and status sits against the dates, so a plan held in one currency can be read against what the channels are showing. That's the display side of the problem, and it's the half you can actually see before a booking happens.

FAQ

Should I list my rates in the guest's currency?

List in the currency you think in, and let the display layer convert. Pricing in a currency you don't hold makes every rate review harder, and the guest sees their own currency either way. The exception is a market where nearly all your demand comes from one country.

Why doesn't my payout match the price on the listing?

Because it was never meant to. The payout is the listing price minus the channel's deductions, converted at settlement. The rate that applies depends on the channel and the payout date, so the two figures differ even when nothing has gone wrong.

Can I fix the rate a booking will settle at?

Not from the listing side. The rate applied is set by the channel's settlement process, and the terms differ between channels. Check the current terms on each channel before you build a pricing assumption around it.

The two numbers will keep differing, and that's fine once you know which one you're looking at. What isn't fine is pricing from the display figure and reconciling against the payout, because the two never meet. If your rate plans and the channels they sell on sit in one view, localsbnb.com is where that view is — nightly rates with their currency, and each channel's source rate against the dates.

---

This article is general guidance for hosts and isn't legal, tax or insurance advice, and it isn't foreign-exchange advice. How a channel displays, charges and settles in different currencies, and which rate applies on which date, depends on the channel and the payout date and changes with its terms. Confirm the position with the competent authority where relevant and check the current terms on each channel before you rely on a figure.