Rate Changes in the Booking.com Extranet, Done Right

Confirm who owns the price, edit in the Extranet, then verify it reached the guest.

Last updated: September 16, 2026

Changing a nightly rate sounds simple until the old number reappears an hour later. Most hosts who run properties in Phuket, Penang, or Bali have seen it: you edit a cell in Booking.com, save, and later the price snaps back because another system still owns that plan.

The Extranet is only one copy of your price. Your channel manager or PMS may hold the master copy. The safest habit is to confirm ownership first, edit in the right place, and then prove the change made it all the way to the guest. This guide focuses on the routine to follow when the Extranet itself is the source of truth.

Find the real owner of the price

Before touching any cell, check if a connectivity partner is active on the account. In Booking.com this usually sits under Account, then Connectivity provider or Channel manager, depending on the region and property type.

The calendar itself is a faster test. If you can click a price cell, edit it, and the new value survives a refresh, the Extranet is likely in charge. If the cell is gray, marked as provider-managed, or flips back after a few minutes, your channel manager is writing to it.

Ownership can be mixed even inside one listing. A standard rate might arrive from your channel manager; a Booking.com promotion is managed inside the Extranet; and a derived rate follows its parent. Note the room type, plan name, dates, occupancy, currency, and current amount before you start. One slip and a studio in Bangkok can inherit the rate meant for a villa in Bali.

A five-step routine for Extranet edits

When the Extranet owns the rate, treat the change as a small project with a closing step. Step five is what keeps your work from being erased by the next sync.

1. Take a picture before you change anything

Screenshot the calendar row for the dates you plan to edit, including restrictions and availability. If the new price behaves oddly, you have a quick way back.

2. Open the right room and plan

In Rates & Availability or Calendar & Pricing, switch to Calendar and choose the list view. Expand the room type, then select the exact rate plan you want to update — Standard Rate, non-refundable, or any other plan. Editing the wrong plan is the fastest route to a rate parity problem.

3. Apply the change to the right dates

For a single night, click the cell and enter the new nightly amount. For a range, drag across the dates or open Bulk edit, then enter the start, end, weekdays, plan, and amount. Leave Rooms to sell alone unless you are intentionally adjusting inventory; price and availability are separate controls.

4. Save, refresh, and compare

After saving, reopen the same dates and check that the stored amount is exactly what you intended. If it differs, the plan may be derived from a parent or controlled by another system. Fix the source, not the displayed cell.

5. Cross-check your own calendar

If you also push rates through a channel manager or PMS, open that calendar next. Make sure the new figure is reflected there, or at least that your next outgoing update will not overwrite the Extranet value. In LOCALSBNB, the calendar shows the source rate for each connected channel, so you can see whether Booking.com is set to receive from your system or accept direct Extranet edits.

When your own system is the controller

If a connection controls the plan, do not edit the price inside Booking.com. Make the change in your PMS, revenue tool, or channel manager, then check the delivery status. A status that says "saved" in your system does not mean Booking.com accepted it. Watch for sent, pending, accepted, rejected, or failed.

Before sending again, verify four details:

• the mapped product is the one you intended on Booking.com;
• the plan you edited is standalone, or its parent plan and the derivation rule are right. The currency, occupancy model, and dates must match what Booking.com expects;
• no newer update has already replaced the value you are looking at.

If Booking.com rejects the message, read the error and fix the root cause — an inactive plan, bad mapping, wrong occupancy, or currency mismatch — then resend only the affected dates.

Or skip the extranet for connected plans: when LOCALSBNB is the controller, you edit once at localsbnb.com and the delivery status tells you the rest.

Prove the change in three places

A rate update is finished only when three numbers agree: the amount stored in your system, the amount shown in the Extranet, and the amount a guest sees in a public search.

Run a guest-facing search in an incognito window, using the same dates, number of guests, room, and currency. Look at the nightly amount, total, taxes, cancellation terms, and any promotion. If the public price is lower, check active Genius, mobile, country, or campaign discounts before blaming the base rate.

Give the system a few minutes, then refresh once. Resending the same range while the first message is still in flight can create conflicts.

If the price reverts or refuses to move

A saved price that flips back is almost always being overwritten by something: a connected system, a scheduled rule, a bulk edit, or a parent-child rate relationship. Compare timestamps to identify the real source.

If the stored price is right but the public price is wrong, the difference usually lives above the base rate — promotions, taxes, fees, currency conversion, or occupancy-based pricing.

If only one plan fails through your connection, compare its mapping and rate model against a plan that worked. Do not refresh the whole property until you know if the issue is a single room-rate pair.

When you escalate, include the property ID, room and rate plan IDs, dates, timestamp and time zone, plus the expected value, the displayed value, and the full error text. Mask any credentials or payment details in screenshots.

Pre-change safety checklist

• [ ] I have confirmed which system owns this rate plan.
• [ ] I selected the correct room type and rate plan.
• [ ] I changed dates, not inventory, unless inventory was the target.
• [ ] I saved, refreshed, and confirmed the stored value.
• [ ] I checked my channel manager or PMS to avoid a later overwrite.
• [ ] I ran a public search and the final price matches my intent.

Frequently asked questions

Which system should I use to update a Booking.com rate?

Edit in whichever system is the source of truth for that plan. If your connection controls it, change it there. Use the Extranet only for plans or promotions intentionally managed by Booking.com.

Why does a price I saved in the Extranet keep changing back?

Another system, automation, bulk edit, or parent rate is overwriting it. Check timestamps to find the system designated as the source.

How can I tell if the Extranet controls a plan?

Editable cells that survive a refresh mean Extranet control. Gray cells, provider-managed labels, or values that revert after a sync mean a connected system is in charge.

Will updating the standard rate also change derived or non-refundable plans?

Only if they are tied to the standard rate. Independent plans need their own update; derived plans apply their stored adjustment.

What if guests see a lower price than the one I stored?

A live promotion, mobile discount, member rate, tax presentation, or currency conversion may reduce the visible total. Compare the same occupancy, currency, and cancellation terms.

Ready to turn rate changes into a five-minute routine? 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)
• [When the Right Room Sells the Wrong Deal: A Rate Plan Mapping Check](/resources/rate-plan-mapping)

---

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.