Cancellation Terms That Survive a Fee Change

Change a rate and the terms attached to it move too. Write the policy so a later edit cannot silently rewrite it.

Last updated: October 24, 2026

A cancellation policy isn't attached to a price. It's attached to a rate plan, and the plan is a bundle: a price, a policy, a minimum stay, and a booking window. Edit one part of the bundle and the rest should hold. The problem is that editing is done in a hurry, and a hurried edit is exactly how a policy ends up attached to a plan nobody meant to sell.

Key Takeaways

• A rate plan is a bundle, not a number. Price, policy, minimum stay and window travel together, and the policy belongs to the plan.
• Anchor the wording to the plan name. A policy written against "the rate of X" breaks the moment the rate stops being X.
• State windows in days, not dates. "A stated number of days before check-in" survives a calendar. "Before 12 May" doesn't survive a season.
• Say what returns, and when. The refund timing is the part guests ask about and the part policies usually leave vague.
• Verify after every edit. Five minutes on each channel after a rate change catches the detachment before a guest does.

What a rate change drags with it

When you change a price, you're usually editing one field. The system may treat that edit as a change to the plan, which keeps the policy attached, or as the creation of a new plan, which starts from a default. Those two outcomes look identical in a rate table and behave completely differently at the moment a guest cancels.

That's the first risk, and it isn't theoretical. Hosts add a seasonal plan, copy last year's, rename it, and inherit whatever default policy the channel applies to new plans. Nobody notices until a guest cancels in week three and the refund that comes out isn't the one on the listing page they read.

The second risk sits in the naming. If your policy says "non-refundable" and your plan names are "Flexible" and "Non-refundable", you're fine until someone renames a plan to "Saver" and forgets that the policy text still refers to a plan that no longer exists. Wording that depends on a label is only as stable as the label.

The third risk is duplication. The same policy has to be right on every channel you sell on, and each channel holds its own copy. Change it in one place, and the other three keep selling the old terms until somebody updates them. That's a publishing problem, not a pricing one, and it's the reason to treat a policy edit as a task with a checklist rather than a field you tweak.

Terms written against the plan, not the price

Write the policy so it names the plan and describes the mechanics. "This plan is refundable up to a stated number of days before check-in" is anchored to a plan and a window. "Cancellations on the 180 rate are refundable" is anchored to a number, and the number will move.

Then describe the mechanics in the order a guest experiences them. When can they cancel free of charge? What happens between that point and check-in? What happens after check-in starts? Each of those is a stage, and the policy should name the stage rather than the money.

Where amounts are involved, say what returns and when, without turning the policy into a rate card. "The cleaning fee is returned in full if the stay hasn't started" is specific and stable. A policy that lists percentages of the total tends to need rewriting every time the total changes, and it invites arguments about which total.

Keep one policy per plan, and as few plans as your pricing actually needs. Every extra plan is another place the same policy has to be correct. Hosts who run four plans usually need two, and the two are easier to keep honest.

There's a sequencing point here that saves trouble later. Decide the policy before you build the plan, not after. A plan built first tends to inherit a default, and defaults are what produce the surprises.

The guest-facing wording

The guest reads the policy once, on a phone, usually at the moment they're deciding. Write for that moment.

Lead with the one thing that matters: whether they can get their money back, and until when. Then the stage after that. Then the exception, if there's one. Three short paragraphs beat a table of tiers, and they beat a paragraph of contractual language that a guest will skim and misread.

Avoid the phrase that causes most disputes: "subject to the policy in force at the time". It sounds careful and reads as a warning that the terms may change under them. If the terms can change, say when and for whom, and say that a booking keeps the terms it was made under.

Put a date on the wording. "Last updated" is a small line that does two things: it tells a returning guest the terms may have moved, and it tells you which version you're reading when a question arrives six months later.

Then read it once as a guest would, on your own phone, on the actual listing. Not in the editor. Editors hide the step where the text gets truncated, and truncation is where a clear policy becomes a vague one.

Re-checking after every edit

Every rate edit gets the same five checks, on every channel, before you move on.

First, open the rate plan and confirm which policy it carries. Not what the policy says in your notes — what the plan shows.

Second, confirm the guest-facing text matches that policy. A plan can be right while the description on the listing is a version behind.

Third, confirm the window. If the plan gives it in days before check-in, the listing gives the same window, and the confirmation email gives the same one again.

Fourth, confirm the old plan is gone or archived. A duplicated plan left live is a plan somebody can book with the wrong terms attached.

Fifth, note the date and what changed. One line in a log, and when a guest disputes something in eight weeks you'll know which version applied.

The calendar view on localsbnb.com shows each connected channel's source rate and status beside the dates, which makes the fourth check visible: a plan left live on one channel shows up as a rate that shouldn't be there. That's the cheapest way to catch the copy that didn't get archived.

Do this on the day of the edit, not at the end of the month. The whole point is to catch a detached policy while you still remember what you meant to do.

FAQ

Does changing a price change the cancellation policy?

Not by itself, and that's the trap. The policy stays attached unless the edit created a new plan or inherited a default. Check the plan after the edit rather than assuming either outcome.

Can I use one policy across all my rate plans?

You can, and for most small portfolios you should. One policy means one place to be right and one thing to explain to a guest. Differentiate on price and minimum stay first, and add a second policy only when there's a reason a guest would understand.

What about bookings made before the change?

A booking carries the terms it was made under, so a later edit shouldn't reach back into it. Where a change would affect an existing stay, check local consumer rules before you act, and put anything you agree in writing.

None of this needs a legal document, and none of it is about being clever with wording. It's about making the policy a property of the plan, then verifying it after the edit that was supposed to leave it alone. If your plans and the channels they're sold on sit in one view, localsbnb.com is where that view is, with each channel's source rate and status beside the dates.

---

This article is general guidance for hosts and isn't legal, tax or insurance advice. What a cancellation policy may say, how much notice it can require and what a guest is entitled to differ by jurisdiction and by channel. Confirm the position with the competent authority, check local consumer rules, and check the current terms of each platform you sell on before you publish a policy or change one.