Price Push Failures: Mapping, Rate Plans and Time Zones

A rate that never arrives on the channel is almost never a sync bug. It is one of three mapping mistakes, and each one leaves a different trace.

Last updated: October 14, 2026

You changed a rate on Thursday. By Saturday the channel still shows the old one. The reflex is to push it again, and that reflex is the reason this takes a week to fix. A failed rate change leaves a readable trace on both sides, and pushing again overwrites it. Read the trace first, and most of these resolve in one sitting.

Key Takeaways

• A missing rate is a message, not a fault. It tells you which of three links broke: the room, the plan, or the date.
• Retrying destroys the evidence. The second attempt overwrites what the channel last received, so write down what you see first.
• Each cause has a signature. Nothing at all points to mapping, some plans moving points to a rate plan, one day off points to a time zone.
• Fix one cause at a time. Changing three settings between checks leaves you unable to tell which one worked.
• Confirm the source, not the screen. A channel page that looks right in your browser isn't proof of what the channel is reading.

Start with the trace, not the retry

Before you change anything, write four things down: the date, the unit, the channel, and the rate each side currently shows. That takes two minutes and it's the only record you'll have of what went wrong.

Then look at where the two sides disagree. That disagreement is the trace, and it's narrow enough to sort into three shapes.

The first shape is silence. The channel shows nothing for those nights: no rate, no availability, sometimes no unit. Silence means the channel doesn't know the room exists under your connection, which is a mapping problem.

The second shape is partial movement. Some nights update and others don't. The weekend rate moves and the midweek rate doesn't. A plan you recognise appears on the channel while the plan you edited doesn't. Partial movement means the channel is reading a different plan from the one you edited.

The third shape is a shift. The rate is correct but it sits one day early or one day late, or a single night at the edge of a range has no rate at all. A shift means both sides are reading the same value on different clocks.

LOCALSBNB's calendar shows each connected channel's source rate and source status, which is the fastest way to see whether a channel is still reporting and what value it's reporting. Use it as your record sheet before you touch a single field.

Cause one: the room is not mapped

A connection links two records, not two products. On your side there's a unit. On the channel's side there's a room or a unit with its own identifier. Until those two are paired, a rate has nowhere to land.

Mapping breaks in ordinary ways. You add a second unit after the connection was set up and never map it. A channel record gets re-created when access is re-established, and the old pairing points at nothing. A duplicate record appears after an import, and the rate goes to the copy nobody is looking at.

The trace is consistent: the channel holds the unit, the calendar shows it, and no rate ever appears for any date. Not a wrong rate. No rate. If you're seeing a number that's simply out of date, you're probably in the next section instead.

The fix is a pairing, done deliberately. Map that specific unit to that specific room, then confirm the pairing is live by reading the source status rather than refreshing the channel page. A page that renders isn't the same as a connection that's reporting.

One habit prevents most of these. After any change to your unit list — a new unit, a rename, a re-import — open the channel side and check that the number of mapped rooms still matches the number of units you expect to sell.

Cause two: the rate plan is not attached

Channels don't read your whole rate table. They read a specific plan, and a plan is a container with its own dates, its own cancellation terms and its own link to a room. Edit a plan the channel isn't reading and your change is real on your side and invisible on theirs.

The common version of this mistake is seasonal. You build a second plan for the high season because the terms differ, you edit it carefully, and the channel keeps reading the original. Another version is structural: the plan exists, the room is mapped, but the plan was never attached to that room, so it has no destination.

The trace here is uneven. Some rates move because they live in the plan the channel reads. Others don't, because they live in the one it ignores. If a weekend rate updated and a midweek rate didn't, don't look at the calendar. Look at which plan each one belongs to.

Attaching a plan is a two-part job. First identify which plan the channel is actually reading; the source status will tell you which value it last received, and that's usually enough to name the plan. Then either edit that plan or attach the new one to the mapped room and retire the old one.

Retiring matters. Two plans attached to one room, both live, both readable, produce rates that alternate depending on which one the channel read last. That looks exactly like a sync bug, and it's not.

Cause three: the date boundary moved

Two clocks run on every listing. One is the property's local time, which is what you're looking at when you make the change. The other is the boundary the channel uses to decide which night a rate belongs to. They usually agree. At the edges of a day, a season or a daylight-saving change, they don't.

The classic case is an evening edit. You set a seasonal rate at 23:40 local, the change is recorded against one date on your side and lands on the adjacent date on the channel. The value is right, the night is wrong, and the guest sees a price that doesn't match the calendar around it.

The second case is a range with two ends. A rate that runs "from the first to the last night" and a rate that runs "until the morning after" are the same instruction written two ways. The difference shows up as one night at the boundary carrying no rate.

The third case is a property time zone set once, wrongly, and never revisited. It sits quietly until a seasonal change makes it visible, and then it looks like every boundary is off by the same amount.

The fix is boring and it works. Make boundary edits in the middle of the local day, not at either end of it. Set the property time zone once per channel and check it after any relocation or account change. And when you edit a range, read both ends before you close the screen.

If you'd rather see the value and its status side by side while you check the ends, localsbnb.com keeps each connected channel's source rate on one calendar instead of four tabs.

FAQ

How do I tell a mapping problem from a rate plan problem?

Look at how much moved. If nothing appears for any date, the room isn't mapped. If some nights or some plans update while others don't, the channel is reading a plan you didn't edit.

Should I push the rate again before I diagnose it?

No. A second attempt overwrites the trace you need. Write down what each side shows, then fix the cause, then send once and confirm the result.

Why does the rate land one day off?

Your side and the channel are working from different day boundaries. Evening edits and seasonal edges are where that shows up, and a property time zone set wrongly makes it happen at every boundary.

Can I check what the channel is actually reading without opening each channel?

You can check what each connection last reported. LOCALSBNB's calendar shows the source rate and source status per channel, and its read-only questions cover the room-type calendar and channel rates, so you can confirm the value before you go looking for a cause.

Three causes, three traces, one order. Read before you retry, fix one link at a time, and confirm the source rather than the screen. Most rate failures aren't mysterious. They're just diagnosed in the wrong order, and localsbnb.com gives you a single place to see what each channel last received while you work through them.

---

This is general advice for hosts, and it isn't legal, tax or insurance advice. Channel behaviour, mapping rules and platform terms vary by place and change over time; check the current documentation and terms of each platform you use.