Editing Rates in the Booking.com Extranet: A Safe Sequence

The extranet will accept almost any change you make. That is exactly why the order matters.

Last updated: September 18, 2026

You open the Booking.com extranet to nudge a nightly rate, and the field takes the number without a warning. The extranet will accept almost any value you type, which is precisely the danger: a rate that is wrong by a digit sits live until a guest books it. This article gives a safe sequence for editing rates in the extranet, names the three layers a Booking.com rate moves through, and shows how to read the confirmation before you trust it. It stays within rate editing and the extranet; tax and legal positions are matters for a local professional.

Key Takeaways

• The extranet accepts nearly any input, so the safeguard is your sequence, not a warning from the system. The tool assumes you are the rate authority.
• A Booking.com rate moves through three layers — the rate calendar, the rate plan and the policy layer. A change that skips one leaves a gap a guest can book into.
• Edit the rate in your master, then confirm the extranet shows it. Editing twice, once in the extranet and once in a manager, creates a conflict the next pull resolves against you.
• Commission is calculated on the total booking subtotal including cleaning and extra-guest fees. A rate error therefore swings a larger payout than the headline percentage suggests, with payment processing sitting below the commission line.
• Read the confirmation as a receipt, not a promise. Check the dates, the room or rate plan, and the number before you trust it landed.

Why the extranet accepts changes so readily

The extranet is built to record your decision, not to judge it. Unlike a consumer app that blocks odd input, the extranet treats you as the rate authority and stores whatever you submit. That design is right for a professional tool, but it means the entire cost of a typo is borne by you, with no "are you sure" between you and a live, underpriced night.

The protection is therefore external. It lives in your own sequence and in a verification step you perform after saving, not in a validation message you hope to see. If you also run a channel manager, the extranet is only one of several places the rate can live, and a direct extranet edit can be overwritten — or can overwrite — on the next sync pull. Decide a single master before you touch anything, because the extranet will not decide for you.

The rate calendar, the rate plan and the policy layer

Three layers sit between you and the price a guest sees on Booking.com, and a safe edit touches all three in the right order. Skip one and the visible price diverges from what you intended.

The rate calendar. This holds the per-night base price for each room type. It is the layer most hosts edit and the one a rate error usually starts in.

The rate plan. A rate plan is a packaged offer — non-refundable, breakfast included, a length-of-stay deal — that references the calendar but can carry its own rules and a derived price. A plan left pointing at old dates is how a night sells under your floor even after you fixed the calendar.

The policy layer. Restrictions decide whether a priced night can be booked at all: a two-night floor, a hard stop on Saturday arrivals, a booking window that shuts on short notice. A restriction you forgot can block the nights you just opened or force a longer stay than the guest wants.

Layer	What you set	What goes wrong if missed
Rate calendar	Per-night base by room	The night sells at the wrong base
Rate plan	Packaged offer referencing the base	A stale plan undercuts the calendar
Policy layer	Stay restrictions	Priced nights become unbookable or forced

One more reason the rate matters: Booking.com commission is applied to the total booking subtotal, including cleaning and extra-guest fees, with payment processing sitting below the commission line. Programme stacking can raise the effective commission — industry estimates put Preferred and Genius combinations at 20–25% or more, plus processing of roughly 1.1–3.1% — so confirm the current position with the platform before you rely on any single percentage. The base you set drives a larger payout swing than the headline rate implies.

A change sequence you can repeat

A repeatable sequence keeps the extranet from becoming the place errors go live. Follow it and the rate lands where you meant it to.

1. Decide the target rate and dates in your master system first. Know the room, the nights and the number before you open the extranet.
2. Pick the master and stay with it. If a channel manager is your master, let it push to the extranet. If the extranet is your master, edit there and let it pull into the manager. Never do both.
3. Edit the rate calendar for the room and dates. Change the base price only on the chosen master.
4. Walk every rate plan that references that calendar. Confirm each plan shows the intended price and is not carrying a stale derived amount or an old date range.
5. Review the policy layer. Make sure no restriction is blocking or forcing the nights you just priced.
6. Save, then read the on-screen confirmation and the rate overview for the dates. Do not walk away at "save."

A manager that connects Booking.com by API, such as the one at localsbnb.com, lets the extranet be a mirror of your master calendar rather than a second place to edit. The steps that stay yours are the plan walk-through and the final read of the confirmation.

How to read the confirmation before you trust it

The confirmation screen is a receipt, not a guarantee, and three fields decide whether to trust it. Checking them takes a minute and prevents the weeks-later surprise of a booking at the wrong number.

The dates. Does the change cover exactly the nights you intended, or did it roll forward to a wider range than you meant? Extranet date ranges are easy to over-select, and an over-wide range is the most common silent error.

The room or rate plan. Did the change land on the right room type and the right plan, or on a sibling plan you forgot existed? A plan that shares the calendar can inherit the edit and show a different visible price than the base.

The number. Does the displayed nightly amount match, before any plan-derived adjustment? Read the base, then read what the plan does to it, because the guest sees the after-plan number.

Remember that a "saved" state in the extranet still has to survive the sync with your manager. If the two disagree, the next pull resolves the conflict, possibly against the number you wanted. So verify the agreement between the two systems, not merely that the extranet accepted the save.

Self-check before you list or publish

1. Did I choose a single master system before editing, or did I edit both the extranet and my manager? Double edits create a pull conflict.
2. Did I walk every rate plan that references the calendar, or could a stale plan still undercut the base? Plans inherit edits in ways the base does not.
3. Did I check the policy layer, or could a restriction be blocking the nights I just opened? Priced nights can still be unbookable.
4. Does the confirmation show the exact date range I intended, or did it roll wider? Over-wide ranges are the common silent error.
5. Is the displayed number the base or the after-plan price? The guest sees the after-plan number, so read both.
6. Have I confirmed the current Booking.com commission position, since it applies to the total subtotal including cleaning and fees? Programme stacking changes the effective rate.

Frequently asked questions

Can I edit rates directly in the extranet if I also use a channel manager?

Yes, but pick one master. If the manager is master, let it push to the extranet; if the extranet is master, let it pull into the manager. Editing both sends two versions into the same sync pull, and the wrong one can win.

Why did my rate change not appear on Booking.com?

Sync runs on a pull cycle, not an instant push, so the change is saved in one system and still en route to the other. Confirm the current position after the sync window rather than editing again, which would create a conflict.

What is the difference between a rate plan and the rate calendar on Booking.com?

The rate calendar holds the per-night base price by room type. A rate plan is a packaged offer built on that base — non-refundable, breakfast included, a length-of-stay deal — that can carry its own rules and a derived price. Fixing the calendar without checking the plan leaves the plan selling at the old number.

Does Booking.com commission apply to cleaning fees?

Commission is calculated on the total booking subtotal, which includes cleaning and extra-guest fees; refundable deposits are not counted, and payment processing sits below the commission line. Programme stacking can raise the effective rate, so confirm the current position with the platform rather than assuming one percentage.

Let the extranet reflect one calendar instead of fighting it. Keep Booking.com rates in step from localsbnb.com.

---

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.