When a Channel Adds a New Fee Field: What to Re-map
Channel Management

When a Channel Adds a New Fee Field: What to Re-map

Localsbnb Editorial TeamOctober 17, 20267 min read

A channel can add a fee field that your side never maps, and an unmapped field reads as zero. Zero is a price, and a price is a promise. Re-map in a fixed order, test on one listing, and give guests a short honest answer while it settles.

Screenshot of the LOCALSBNB settings screen used to illustrate re-mapping after a channel adds a fee field
The settings a host re-checks after a channel adds a fee field.

A new field on a channel is not a new field on your side until you map it. Until then it reads as zero, and zero is a price you will honour.

Last updated: October 9, 2026

A channel can add a fee field to its own booking form and change nothing on your side. Until you map that field, your setup reads it as zero. Zero isn't a neutral placeholder — it's a number the platform quotes to a guest, and a number you're expected to honour. This guide puts the re-mapping in the order that stops a booking from selling at a price you never set.

Key Takeaways

  • A field you haven't mapped reads as zero. The platform treats a missing number as nothing, and nothing becomes a price it will quote to a guest.
  • Re-map in a fixed order. Start with the fields that change what a guest pays, then the ones that change what you receive.
  • Test on one listing before the rest. One listing shows you the whole chain, including the parts you didn't expect to touch.
  • Give guests one short, honest answer. A holding line beats four different explanations as the mapping settles.
  • Every field follows current terms. Names and rules change by platform, so re-check the channel's own documentation each time.

Why an unmapped field reads as zero

A channel's fee field and your fee field aren't the same object, even when they share a name. The platform added a slot on its booking form. Your setup has its own slots, built for the fields you already carry. When a new one arrives, nothing lands on your side on its own.

Here's what happens in the gap. Most booking systems store money fields as numbers, and a number that's never been set defaults to zero. Zero doesn't look broken. It looks like a choice. The field is present, the booking is valid, and the total is quietly missing one line.

The cost shows up later. A guest books at a total that omits the new fee. The channel treats that total as the agreed price, because as far as its records go, the guest was quoted it and accepted it. You discover the gap when the fee should have appeared on the booking and didn't. The platform didn't break. Your side simply never learned the field existed.

One more thing makes this easy to miss. The change usually arrives as an announcement, not as an error. Nothing on your dashboard turns red, and the bookings keep coming. The only visible symptom is a number that's slightly lower than you expected, which is the easiest kind of problem to explain away.

The pattern repeats across platforms, which is why it catches hosts who sell on more than one. Each channel has its own field names and its own timing for changes. A host who only maps on the channel that sent the loudest notice can still be carrying the same gap on the other three.

The fields to re-map in order

Not every field carries the same risk, so don't re-map in the order the platform lists them. Re-map in the order a mistake costs you money.

Start with the fields that change what a guest pays. A fee added to the guest's total, a tax the channel collects, an extra-guest charge — these move the headline number. Take them first, because a guest-facing field that reads as zero is the one that sells a booking at the wrong price.

Then take the fields that change what you receive. A commission, a payment-processing line, a payout adjustment. These don't alter the guest's total, but they decide your net, and a wrong net is a slow leak rather than a single loss.

Then the fields that only affect reporting. A code, a category, a note. These matter last, because a booking still completes without them and nothing is mispriced.

As you work the list, map one field, save it, and confirm it took. Batching several fields before you save makes it impossible to tell which one failed when the total ends up wrong. Check each one against the channel's current documentation as you go, since field labels get renamed between seasons and last year's screenshot won't match this year's form.

One way to find the fields you've missed is to read a completed booking backwards. Take a recent stay and list every line the guest paid, then list every line your side recorded. Where the two lists differ in length, you've found a field that never made it across. Do that on one booking per channel and the shape of the gaps becomes obvious.

Testing the change on one listing

Don't push a mapping change across every listing on the first pass. Pick one listing, ideally a quiet one you can watch for a few days, and run the whole booking path through it.

Build a test booking by hand. Add the new fee to a stay. Confirm the guest's total moves, and confirm it moves by the amount you mapped rather than by some other number. Then check what lands on your side: the fee on the booking, the effect on your net, and whether the entry reads as you'd expect on a payout.

Look for the quiet failures too. A fee that applies only to certain dates, or only above a guest count, can pass a simple test and still break on a busy weekend. If the field has conditions, test one booking that meets them and one that doesn't. Two bookings catch more than one.

Only after the single listing behaves do you repeat the mapping across the portfolio. When something is wrong, one listing is cheap to fix and twenty aren't.

Watch the first real booking that comes through the test listing, not just the booking you built by hand. A hand-built test follows the path you expect. A real booking arrives with whatever extras the guest added, which is where an unmapped field usually surfaces first.

Card: the guest-facing and host-side fields to re-map after a channel adds a fee field
Guest-facing fields first, host-side next, reporting-only fields last.
Card: the order to re-map fields when a channel adds a new fee field
Map the guest-facing fields first, then test on one listing before the rest.

What to tell guests in the meantime

Bookings won't pause while the mapping settles, and guests deserve an answer that's true now and still true in a week.

Keep it short. Say the booking is confirmed, name the total they'll pay, and note that a fee line is being updated with the channel. You don't need to explain the plumbing. A guest who hears one clear sentence rarely asks a second question.

This is the kind of gap a single view closes. LOCALSBNB connects to four channels in all — Airbnb, Booking.com, Agoda and Trip.com — and its calendar shows each connected channel's own source price and status side by side. Instead of opening four dashboards to find which one changed, you read one calendar and see where a total moved. You can start free at localsbnb.com and map the field before the next booking tests it for you.

Write the holding message once and reuse it until the mapping is confirmed. The moment the numbers stop moving, send the final figure and close the loop.

Keep the message factual and dated. If the mapping takes a few days, a guest who was told the total is being updated won't mind a short wait. A guest who was told nothing and then sees the total change may ask why, and that question is harder to answer calmly.

LOCALSBNB — start free

FAQ

How do I know a channel has added a fee field?

Usually from an announcement or a help-centre note, not from your own dashboard. A booking whose total looks low, or a fee that's empty on a stay where you expected one, is the practical signal. Check the channel's current documentation rather than an email you half remember.

Should I re-map every field the channel lists?

No. Re-map the ones that change what a guest pays first, then the ones that change what you receive, and leave reporting-only fields for last. Mapping a field that doesn't affect money is harmless, but it isn't urgent, and rushing the money fields is how a total goes wrong.

Can I skip the single-listing test to save time?

You can, and it's the fastest way to spread one mistake across your whole portfolio. One listing, two test bookings if the field has conditions, costs a few minutes. Fixing the same error on every listing after a busy weekend costs far more.

The work is small and the window is narrow. Map the field before a booking tests it for you, keep the mapping visible, and the change stays a settings task instead of a refund. You can put the mapping in place today at localsbnb.com.


This is general guidance for hosts, not legal, tax or insurance advice. Local rules and platform terms change, so check the current requirements of your local authority and the terms each platform applies today.

Reviewed by

Localsbnb Editorial Team