Rate-Plan Mapping Across Four Channels: Keeping the Matrix Honest
A rate plan is a bundle of rules, not a number, and each of your four channels names that bundle in its own words. This guide sets out the columns a mapping table must carry before the first push, the two mapping mistakes that publish a wrong price instead of raising an error, and the re-check to run whenever anything inside a plan changes.
Every channel names its plans differently. The mapping isn't paperwork — it's the reason two platforms never quote the same night twice.
Last updated: September 23, 2026
A rate plan isn't the price. It's the bundle of rules attached to it: what the guest may cancel and until when, how many nights they must take, who may see the offer, and what sits inside the number. Your four channels describe that bundle in four different vocabularies. A mapping table records which plan on your side answers to which plan on theirs. When a row is wrong, nothing complains. The night simply sells at a figure nobody chose, and you hear it from a guest rather than from a warning.
Key Takeaways
- A plan is a bundle, not a number. Rate, cancellation window, minimum stay and inclusions move together; map all four, never the price alone.
- Four vocabularies, one meaning. Airbnb, Booking.com, Agoda and Trip.com each attach their own words to the same underlying idea.
- Six columns before the first push. Without them the table cannot be audited, and an un-auditable table is decoration.
- Two errors fail silently. A plan mapped to nothing, and two plans mapped to one target, both publish a price instead of raising an error.
- Inclusions invalidate the row. Any edit to what a plan contains puts that row back in question until you read the price back.
What a rate plan means on each of the four connections
On your side the idea is simple: one night, one price, one set of terms. On the channel side the same idea has been cut up differently. And each of the four chose a different place to make the cut.
Some treat the plan as a wrapper around the rate, so the cancellable and non-cancellable versions of one nightly figure are two separate objects. Others treat the unit-and-rate pair as the sellable item, so one plan of yours appears once per occupancy level. Others let a promotion layer on top. Then the price a guest sees is the plan plus something you never put into it.
That difference is why copying a label from any article, this one included, is a poor way to fill a table. Portal wording varies by language, region and account type, and it changes during redesigns. What you need from each channel isn't a definition of the word. It's four answers, read off your own screen:
| Read this off the portal | Why it decides the mapping | If you skip it |
|---|---|---|
| The exact label shown for the plan | The label is the address your mapping writes to | You map to a name that no longer exists, silently |
| Whether the rate is per night or per occupancy | It changes what one "price" means | The same number buys different things on two platforms |
| Where cancellation terms live: inside or beside the plan | If beside it, editing the plan will not move them | You change a plan and the terms stay a year old |
| Whether a promotion can layer on top | A layered discount applies after your push | The published figure lands below your floor |
Read those four once per portal, write them down, and date the note. The vocabulary isn't the point. The four answers are.
Building the mapping table: the columns that have to exist before the first push
A mapping table is a spreadsheet, and its value comes almost entirely from the columns people leave out. Six are load-bearing.
Your plan name. The one you control, named so a stranger could tell two of them apart without asking. "Two-night refundable" beats "Plan B" at midnight.
Channel and channel label. One row per channel per plan, with the label exactly as that portal shows it today. Never a row that says "all channels" — the moment one differs, you've lost the ability to find it.
Rate basis. Nightly, per occupancy, or tiered by length of stay. This column catches the most expensive mistake in the table. A nightly figure pushed into a per-occupancy slot reads as valid, and quietly multiplies.
Cancellation and prepayment window. Free until how many days out, what is charged after, whether a deposit is taken at booking. Two plans differing only here look identical on a calendar. They behave nothing alike.
Restrictions. Booking window, the minimum and maximum nights a stay may run, days closed to arrival, and which guest segments may see the offer. A promotion aimed at a closed group is the usual reason one channel shows a price the other three never will.
Inclusions and fee treatment. Cleaning, extra-guest charges, taxes, anything billed separately. If a fee sits inside the plan on one channel and outside it on another, the two numbers aren't comparable, and your mapping has to say so.
Add two more that aren't about the plan at all: who last verified the row, and when. Every mapping table that's ever gone stale went stale because nobody owned that column.
The two mapping errors that quietly produce a wrong price rather than an error message
Most people expect a mistake to announce itself. These two don't, and that's why they survive for months.
The first is a plan mapped to nothing. You build a plan on your side, point it at a channel plan, and push. If the target was renamed, archived or deleted since you wrote the row down, the push doesn't fail. The channel receives a rate and files it where you didn't intend, often against a default plan with its own cancellation terms. The symptom isn't an error. It's a night sold at a figure you never set, under terms you never chose, with a confirmation email that looks entirely normal.
The second is two of your plans mapped to the same target. It happens after a promotion season, when a temporary plan is created alongside an existing one and pointed at the same channel plan for convenience. Both write to one address. The last push wins, and which one is last depends on processing order. The published price then alternates. To a guest that reads as dynamic pricing; to you it's a mystery.
Detection is the same for both, and it takes five minutes. Pick one date two months out on one unit. Read what each channel returns for it on its own booking screen, as a guest sees it — not what your side says it sent. Three agreeing and one disagreeing is the signature of both errors. One calendar read across all four connections removes most of the typing. Availability and rates for Airbnb, Booking.com, Agoda and Trip.com sit on one grid at localsbnb.com. Each row shows the source rate and source status that channel is holding. So you see a mismatch where you already work, not in four separate logins.
Re-checking the matrix after any change to a plan's inclusions
A mapping doesn't go stale on a calendar. It goes stale on an edit. Change what a plan contains and every row pointing at it becomes a question again.
Four edits do this most often. Moving a cleaning charge in or out of the nightly figure. Changing the number of guests included before an extra-guest charge applies. Adding or removing a length-of-stay discount. Altering how taxes appear at checkout. Each one changes the meaning of the price without necessarily changing the number, which is why a glance at the rate won't catch it.
The re-check is mechanical. Change the inclusion on your side and push. Read the published price back on each channel's guest-facing page for one test date, and confirm the inclusions shown match what you now intend. Then write the date and your initials into the last-verified column for every row you touched. That third step is what makes the first two worth doing.
Cadence follows the same logic. Re-check a row the moment its plan changes. Re-check the whole matrix monthly, on a date you can defend. And re-check everything after any channel redesigns its interface — that's the moment a field your mapping pointed at stops existing without telling anybody.
FAQ
Do I need one plan per channel, or one plan mapped to four?
One plan on your side, mapped once per channel. Four plans with identical rules are four things to keep in step, which defeats the purpose. Create a second plan only when the rules genuinely differ.
Why is one channel showing a price the other three don't?
Start with restrictions, not rates. A closed group, a member-only promotion, or a minimum stay that differs by one night produces a price some guests see and others never do. And from where you stand, it looks exactly like a sync fault.
How often should the whole matrix be re-read?
Monthly for the full table, plus immediately after any inclusion change and after any channel interface change. The monthly pass is cheap once the last-verified column exists, because you're reading rows rather than rebuilding them.
Two errors, one detection method, one column nobody fills in: that's most of what goes wrong with rate-plan mapping. Put a name and a date on every row. Read one test date back from each channel's own screen each month, and treat any change to a plan's inclusions as a reason to re-read the row. If you'd rather see all four channel calendars side by side before the first table, they sit on one grid at localsbnb.com.
Rate structures, plan labels and fee treatment differ by platform, region and account type and change without notice; read every figure and label off your own extranet, and treat the current settings in each platform's own admin as the authority.
Reviewed by
Localsbnb Editorial Team