When the Right Room Sells the Wrong Deal: A Rate Plan Mapping Check

Find which rate plan wire points at the wrong offer, then prove the round trip.

Last updated: September 16, 2026

Your calendar says one price. The OTA shows another — or a guest books "free cancellation" and the booking lands as non-refundable. The room is fine. The connection reports healthy. The problem lives one layer deeper, in the link between your rate plan and the channel's offer.

That link is called a mapping, and when it points at the wrong deal, everything you push and everything you receive lands in the wrong place. Here is how to find the break in about ten minutes — before you delete anything, rebuild anything, or make it worse.

First, recognize what a mapping mismatch actually is

A rate plan is not just a price. It is a bundle: the price logic, the cancellation and modification rules, what is included, when payment happens, who it can be sold to. Your side holds one plan; the channel holds its mirror image, the offer. A mapping is the wire between them.

A mismatch means the wire runs to the wrong offer. Typical evidence:

• Your rate update changes the price of an offer you never meant to touch.
• A booking arrives with cancellation or meal terms that don't match what the guest saw.
• One plan's dates update correctly, but the public price and conditions attached to them are wrong.
• The connection log shows green across the board — because the data reached a target, just not the right one.

That last point trips people up most. A successful sync proves delivery, not correctness. The system sent the data where you told it to send it.

Not every price gap is a mapping problem

Before you touch configuration, rule out the honest explanations: promotions, taxes and fee display, currency conversion, mobile-only discounts, derived-rate formulas, and cached search results can all make two prices differ for legitimate reasons.

A genuine mismatch exists only when the plan identifier on one side is wired to a deal the other side never meant to sell. If you can't see that in the evidence, stop here and look elsewhere.

The 10-minute diagnosis: three questions

1. Which direction is wrong? Rates flow out from your system to the channel; reservations flow in the other way. If your pushed price lands on the wrong offer, that's an outbound problem. If a correct OTA booking imports under the wrong internal plan, that's inbound. They travel on separate paths — either one can break alone, so diagnose one direction at a time.

2. Do the IDs actually match? Compare identifiers, never names. Pull the plan ID from your side, the offer ID from the channel, and check the mapping record that connects them. "Standard Flexible" and "BAR" might be the same deal — or two different ones. Names support the conclusion; IDs are the conclusion.

3. What changed recently? Most mismatches begin with a structural change: a plan renamed or recreated, a channel reconnected, a room cloned, a switch from standalone to derived pricing. One side mints a new ID, the old link stays selected, and the wire quietly runs to a product that no longer exists — or to one that shouldn't.

Protect guests before you fix anything

If the wrong offer could sell something you can't honor — an unavailable inclusion, a lenient cancellation policy on a strict rate, a loss-making price — pause that one plan first. Close only the affected plan, not the room itself, and only for as long as the diagnosis takes.

Then preserve what exists. Export the affected bookings with their channel confirmation numbers, the plan they were sold under, prices, conditions, and stay dates. Deleting a plan can orphan every future modification and cancellation attached to it — so never delete anything while live bookings still depend on it.

See it from the guest's side

Once you suspect a mismatch, compare the two views directly: your calendar's stored price for specific dates versus the public price for the same dates, occupancy, and currency on the channel. That side-by-side is usually where the mismatch stops being abstract.

Correct one wire, then prove the round trip

When the wrong link is confirmed, resist the urge to rebuild the whole connection. Fix the smallest thing possible:

1. Pick a low-demand future date with open availability for testing, and note the current rate and restrictions everywhere.
2. Replace only the incorrect plan-to-offer link. Leave the property, room, and inventory links alone — they were never the problem.
3. Send one controlled update through your usual system, then confirm it arrived on the exact intended offer — and that neighboring offers didn't move.
4. Search the channel publicly with matching dates, occupancy, and currency, and check the price and the conditions.
5. Place a test booking you can cancel: confirm it imports under the right plan, then modify it, then cancel it.

If fixing one plan requires disconnecting the whole room or property, stop. A broad disconnect interrupts the products that are working correctly. That's the moment to bring in your connection provider with the evidence you've collected.

With LOCALSBNB managing room types and rate plans for you, most of this wiring disappears: the mapping is handled at localsbnb.com, and you confirm it once instead of rebuilding it.

Bookings already made under the wrong plan

A mapping fix prevents future errors; it does not repair history. For imported bookings, keep the channel's confirmation as the commercial record of what the guest actually bought. Honor the price and terms the guest saw. Correct your internal records through your platform's normal editing workflow, and reach out to the guest only if a material difference needs to be acknowledged — never frame an internal wiring mistake as the guest's problem.

When the symptom survives the fix

• The right offer changed but the price still looks wrong — check the layers above the mapping: promotions, taxes, currency, derived formulas. Fix that layer; don't remap again.
• New bookings still import under the old plan — inbound and outbound may use different mappings. Bring both IDs and your test booking to support.
• The mapping reverts after saving — something else owns the configuration: another account, a template, the provider. Find the owner, change it once.
• No valid plan exists on your side — the channel sells something you can't represent. Confirm the design with your provider; don't map it to the closest-sounding name just to clear a warning.

Close the incident with proof, not with a screenshot of a mapping screen: one controlled update landed on the right offer, unrelated plans stayed unchanged, public conditions match, and a full booking-modify-cancel cycle ran through the correct plan. Save those IDs and timestamps — the next plan you create will thank you.

Frequently asked questions

What exactly is a rate plan mapping mismatch? A link between one system's rate plan and a different offer on the channel side. The room can be correct while the price logic, cancellation terms, inclusions, or payment flow are wrong.

Can the connection show green while the mapping is wrong? Yes. A green log means the message arrived where it was pointed — it says nothing about whether that destination is the deal you meant.

Should I delete and recreate the rate plan to fix it? Not before protecting live bookings and identifying the exact wrong link. Deletion can break future modifications, cancellations, and reporting attached to the existing bookings.

Why do my pushed rates work but bookings import wrong? Because the two directions can use separate paths and separate mappings. Test and document both before assuming one fix covers both.

How do I verify a corrected mapping? One controlled update to the intended offer, a public search with matching dates and occupancy, then a cancellable test booking that imports, modifies, and cancels under the right plan.

Ready to trust every rate plan on your calendar? Start free at localsbnb.com.

Keep reading

• [The Real Cost of an OTA Booking: Commission Math Every Host Should Run](/resources/ota-commission-math)
• [Changing Rates on Agoda? The Routine That Keeps Your Sync Intact](/resources/agoda-rate-change)
• [Rate Changes in the Booking.com Extranet, Done Right](/resources/booking-rate-change-routine)

---

Fees, rates, and platform policies change, so confirm current details with each channel before acting. Results vary by market, season, property type, and pricing. LOCALSBNB provides software, not financial or legal advice.