The Cost Table Guests Screenshot

A clear total gets screenshotted and shared. A vague one gets screenshotted and complained about. Same photo, different outcome.

Last updated: November 1, 2026

The person deciding your booking is often not the person reading your listing. It's whoever receives the screenshot. That's why the cost table matters more than the description around it: one image, sent to a group chat at eleven at night, either answers the question or starts an argument. A table with one total on top does the first.

Key Takeaways

• The screenshot is the reading surface. Design the table for a phone screen, not for a browser on a desk.
• One total, then the lines. A total with detail underneath reads as honest. Detail with no total reads as a trap.
• Three columns is the whole table. What you pay, what's inside it, when it's due. Anything else belongs in a second table.
• Put it above the amenity list. A guest who has to scroll to find the price has already compared you on price alone.
• Date it. An undated table becomes wrong quietly, and a wrong total is worse than a missing one.

What a guest is actually comparing

By the time someone reaches your listing, they've seen nine others. They aren't reading anymore. They're scanning for the number, taking a screenshot, and moving on, and the screenshot is what gets discussed.

That changes what the table has to do. It has to survive being looked at for four seconds on a phone, next to three other screenshots of three other flats. The guest holding the phone is asking one question: what does this actually cost for the nights I picked? Everything in the table either answers that or gets in the way.

Watch what happens with a vague table. The guest screenshots it anyway, because the number at the top looked acceptable, and then finds the cleaning charge, the extra-guest charge and the deposit at the payment step. The second screenshot is the same image with a worse caption, and it goes to the same group chat.

So the design goal isn't persuasion. It's a total that survives contact with a stranger who is comparing four tabs at once and doesn't trust any of them.

Three columns, one total

Build it as three columns and keep it there.

Column one is the total. One number for the stay the guest searched, in the currency they searched in, with the dates it applies to. Bigger than everything else on the image. If the total can't be stated for a date range, the table isn't ready.

Column two is what's inside it. The nights at the rate you set, the cleaning charge, the extra-guest charge if there is one, the fees and taxes that apply where you let. Any discount already taken off gets its own line. No percentages and no arithmetic for the guest to do — just the lines that add up to the number in column one.

Column three is when it's due. A deposit now, the balance on a stated date, a refundable damage deposit that comes back after checkout. Amounts belong here too, but the point of the column is timing, because timing is the thing guests get surprised by.

Then check the order. Total first, lines second, timing third. Reversing it is the most common mistake in a listing table, and it's the one that produces the complaint screenshot: a guest who has to add four lines themselves will assume there's a fifth line waiting at checkout.

Keep it to five to seven rows. If your fee structure needs more, the extra detail goes in a second, larger table further down, or into the price settings where it belongs. A table that needs a scroll isn't a screenshot anymore; it's a document.

One more formatting rule: no "from" prices. A total that starts at a number and moves is the fastest way to make a guest feel switched. State the total for the dates in the header, and if the dates change, the table changes with them.

Where to put it in the listing

Put the table above the amenity list, and above the paragraph about the neighbourhood. Not because the total is the most attractive thing about the flat, but because it's the first thing being looked for. A guest who finds the number quickly reads the rest generously. One who has to hunt for it reads the rest suspiciously.

Then make sure the table and the price settings agree. A table that says cleaning is included, sitting above a price setting that adds a cleaning charge, produces the worst outcome available: a guest who feels lied to and has the screenshot to prove it. The nightly rate lives in the calendar, and the calendar is where you check it. localsbnb.com keeps Airbnb, Booking.com, Agoda and Trip.com in one calendar and shows each channel's source price and status. So the number you put in the table traces back to the rate you actually set, not to one channel's display of it.

Format matters more than you'd think, because channels render text differently. A markdown table that looks tidy in one place can collapse into an unreadable run of pipes somewhere else. If the table has to survive four channels, make an image of it and put the same image everywhere, with the same dates in the header.

Then date it on the image itself. "For stays between these two dates" is enough. An undated table is a table that becomes wrong silently, and the wrongness always surfaces at the worst moment: a guest has booked, paid a deposit, and then reads a number that no longer applies.

The version you keep for yourself

Behind the published table, keep a working copy with everything on it: the rate, the cleaning, the fees, the taxes, the discount, the deposit, and your own costs underneath. That one doesn't go in the listing. It's the one you check the published table against.

Reconcile on three triggers rather than on a schedule. When a nightly rate changes. When a fee or a tax rule changes. When a season changes the minimum stay. Each of those can move the total while the published image stays exactly as it was.

Then keep a version log. One line per version: the date, the dates the table applied to, and what changed. When a guest asks why their total differs from the picture they saw, the log answers it in ten seconds, and the answer is usually that the picture was for different dates.

There's one more use for the working copy, and it's the reason to keep it honest. Building the table forces you to look at the lines a guest sees, in the order they see them. That's where you find the discount that makes the total look smaller than the stay, or the extra-guest charge that only ever appears after someone books for five. Both are easier to fix in your own copy than in a message at midnight.

FAQ

Doesn't a big total put guests off?

A surprise puts them off. They're comparing totals whether you publish one or not, and the only choice you get is whether your total arrives before the comparison or after it. A clear number also filters out the guests who were never going to book at that price.

Should the table show taxes and fees as separate lines?

Show them as lines if they apply to your stay and your jurisdiction, and say plainly whether the total includes them. What matters for the screenshot is that the number at the top already accounts for every line underneath it. A table where the guest has to do the addition is a table that gets mistrusted.

What about weekly or monthly discounts?

Apply the discount as its own line, and date the example. One sample stay, stated dates, the discount taken off visibly. That way the table teaches the guest what a longer stay would look like without promising a rate for dates you haven't priced yet.

A cost table is a small piece of design with an outsized job: it's the part of the listing that travels without you. localsbnb.com gives you one calendar across the four connected channels, which is where the rate behind the total is set and where you can see whether the number on the image still matches the number being sold.

---

This article is general guidance for hosts and isn't legal, tax or insurance advice. What a listing must show about price, taxes and fees differs by platform, by jurisdiction and by the type of stay, and disclosure rules change. Confirm the current requirements with the competent authority and the current terms of each platform you use before you publish a price table.