Rate Push Failed: Mapping, Rate Plan or Time Zone?

A rate that doesn't arrive is almost never a platform problem. It's a mapping, a plan that doesn't exist on the other side, or a date that shifted by a day.

Last updated: October 27, 2026

Three causes sit behind almost every rate that fails to arrive, and they leave different marks. That's the useful part. Before you touch anything, look at what the channel is showing: nothing at all, some of what you sent, or everything one night out. Each shape points at one cause, and the shape tells you whether the fix is yours or somebody else's.

Key Takeaways

• Read the shape before the cause. Nothing, some, or one day out — three shapes, three suspects.
• Nothing at all points at the mapping. The rate is being sent somewhere the channel isn't selling.
• Some of it points at the rate plan. The number arrived; it attached to a plan nobody books.
• One night out points at the date. It's the only cause that produces an off-by-one.
• Write the three lines before you escalate. What you set, what the channel shows, and which shape it is.

Start with the mapping

Start here not because it's the most common cause, but because it's the only one that makes the other two questions meaningless. If the listing on your side isn't joined to the listing the channel is selling, then the rate plan and the date aren't wrong — they have no subject.

The mark it leaves is brutal and easy to read: nothing changes, on any date, for that listing, however many times you send the rate. Not one night moves. And the change you made is visible on your other channels, which is what makes the diagnosis feel confusing — the rate went somewhere, so the rate must be fine.

A mapping break usually arrives through an ordinary event rather than a failure. A listing is recreated on the channel and gets a new identity behind the scenes. A unit is duplicated to save time and the copy inherits a join that points at the original. A property is renamed, or a room type is consolidated, and the record you're updating is now an orphan — still there, still accepting rates, connected to nothing a guest can see.

The way to confirm it is to stop looking at your own screen and look at the channel's. Find the listing as a guest would, on a date you've just changed, and compare. If the guest-facing rate hasn't moved on any date and your calendar says it has, the join is the suspect, not the number.

When the rate plan isn't there

The second cause is partial, and the partiality is the clue. Some nights move and others don't. One rate plan updates and the plan guests actually book doesn't. A change to a weekday price lands, a change to a weekend price doesn't, and the difference isn't the day — it's which plan each one is attached to.

Rate plans are built per channel. A plan on your side carries a name and a set of conditions, and the channel has its own version with its own identity. The two are connected, but they aren't the same object, and the connection survives less gracefully than most hosts assume. A plan retired on the channel side leaves your push aimed at something that no longer exists. A plan renamed on either side can break the correspondence without anyone touching a rate.

The confirmation is the same technique, narrowed. Pick the specific date and the specific plan you changed, look at what a guest sees for that combination, and compare it with what your calendar holds. If your value is right and the public value is stale on that plan while another plan on the same listing moves, you've found it. The number travelled. It arrived in a room nobody books.

This is also the cause that produces the most misleading evidence, because the channel's own screens will often show your new rate on the plan you pushed. Everything on your side agrees with itself. Only the bookable plan disagrees, and the bookable plan is the one that decides what a guest pays.

The time-zone trap

The third cause is the only one that shifts the answer by exactly one day, and that makes it the easiest to confirm once you suspect it. A rate you set for Friday arrives on Thursday. A two-night change moves one of the two nights. A price you edited late in the evening lands on tomorrow, because by the channel's clock it already is tomorrow.

Two clocks are involved: the one attached to the property and the one the channel uses to cut the day. When they differ, every edit made near the boundary crosses into the wrong night. Nothing is broken. The arithmetic is correct and the date is wrong, which is a much harder thing to notice than a number that never arrived.

The test takes a minute and settles it. Set two adjacent nights to values you can't confuse — deliberately different, not two plausible rates. Look at which night each one landed on. If they arrive on adjacent nights but the wrong pair, you have your answer. If one arrives and the other doesn't, you're back at the rate plan.

This cause also clusters. Day boundaries shift twice a year in most places that observe seasonal time, and the days around the change are when off-by-one failures concentrate. If a rate goes missing in the same fortnight every year, the calendar isn't the problem; the boundary is.

Comparing the two sides is where the time goes, and it's the step a single view shortens. LOCALSBNB shows each connected channel's source rate and status in one calendar, so the night you changed and the night the channel holds sit next to each other. You can start at localsbnb.com and read the shift without opening four tabs.

The three-line check before you escalate

Before you ask anyone for help, write three lines. Not a description of the problem — three facts that let someone else reproduce your reading.

The first line is what you changed: the date, the value, and the plan it was meant for. The second is what the channel shows for the same date and the same plan, as a guest would see it. The third is the shape: nothing, some, or one night out. Those three lines take four minutes and they replace an hour of guessing.

The shape also tells you who to ask. A mapping break is yours to fix, because it lives in the join between your records and the channel's. A plan mismatch is a conversation with the channel, because the plan on their side is the one that has to exist. A date shift is a setting on your side, in the property's time zone, and it's usually the last thing anyone checks because it looks like infrastructure rather than configuration.

And the shape tells you what not to do. Sending the same rate again is not a test. It's a repetition, and it destroys the evidence you'd want later: after three pushes, nobody can say what the channel showed before the first one. If you retry, do it once, note the time, and compare across the retry rather than after it.

One last piece of discipline: don't escalate with the symptom alone. "The rate didn't push" is a sentence that starts a conversation about the platform, and the platform is almost never the answer. "I set 180 for the 14th on the flexible plan, the public page shows 165 for the 14th, and every other date moved" is a sentence that ends one.

FAQ

Why did the rate land on three channels and not the fourth?

Because the three that worked are joined to records the channels are selling, and the fourth isn't. A rate that reaches three channels proves the number is fine and the push is fine. It says nothing about the fourth channel's listing, which is where the answer is. Check the fourth as a guest would, on the date you changed.

Could the platform be at fault?

It can be, and it's the last thing to conclude rather than the first. All three causes here are record-level: a join, a plan, a date boundary. Each one produces a specific shape, and none of those shapes looks like an outage. An outage takes everything down at once, across listings and channels, which is a much easier thing to recognise than a single stale rate.

How long should I wait before escalating?

There's no universal number, and any figure would be a guess about someone else's queue. The better trigger is readiness: escalate when you can write the three lines — what you set, what the channel shows, and which shape it is. That's the point at which a support conversation can end in a fix rather than a request for more screenshots.

Three causes, three shapes, one habit. Most rate failures are resolved by looking at the channel instead of the number. The calendar at localsbnb.com is built for exactly that comparison: each connected channel's source rate and status in one view, so a stale rate on one channel sits next to the correct one on another.

---

This article is general guidance for hosts and isn't technical support for any platform. Channel behaviour, plan structures and time-zone handling differ between platforms and change over time. Confirm the current behaviour with each platform you connect, and check your own property settings before you rely on any diagnosis here.