When One Channel's Calendar Lags: Reading Source Price and Source Status

A stale calendar is not always a broken connection. Two fields tell you whether the problem is the data or the timing.

Last updated: October 24, 2026

When one channel's calendar lags, read two fields before you change anything: the source price that channel reports, and its source status. If the status shows the change applied and the price still differs, you have a data problem. If the status shows the change still in flight, you have a timing problem, and editing the rate again only puts another message in the queue.

Key Takeaways

• A lag isn't a diagnosis. It's an observation that needs one more field before it means anything.
• Source price tells you how far apart the two sides are. Your own rate tells you which side moved.
• Source status tells you what happened to your change. Accepted, applied and in flight are three different states.
• Stop editing while a change is in flight. Every extra edit adds a message, and you lose track of which one lands.
• Write the two values down with a timestamp. It's the only evidence that survives the next update.

Two fields worth reading first

The source price is the rate the channel itself reports. Not the rate you set, and not the rate your calendar thinks is live — the number the channel is standing behind on its side of the connection. That distinction is the whole point of the field. It lets you compare two independent statements instead of comparing your intention with your assumption.

The source status is the channel's own account of the connection and the last change: whether it was received, whether it was applied, and where it stopped if it wasn't. Wording differs from channel to channel, so read the state rather than the label.

Read them together, and the field stops being ambiguous. Price alone tells you there's a gap and nothing about why. Status alone tells you the machinery moved and nothing about the result. Together they answer the question you actually have: has the channel taken my change, and if so, why does its number still differ from mine?

localsbnb.com shows both beside the dates: the source price and the source status for each connected channel, with Airbnb, Booking.com, Agoda and Trip.com in one calendar. That's what makes a single lagging channel visible at a glance rather than by opening four tabs and comparing them from memory.

Source price against your own rate

Start by checking your own side. A rate you edited last week, a plan that was replaced, a seasonal rule that took effect on the first of the month — the number you're comparing against may be the stale one, and the channel may be right.

Then classify the gap. Four shapes cover most cases, and each one points somewhere different.

The two numbers match. Nothing is lagging on price. If the calendar still looks wrong, the problem is elsewhere — availability, a minimum-stay rule, a closed date.

They differ by a constant amount on every date. That's usually a basis question rather than a timing one: tax in or out, a fee displayed on one side, a currency conversion applied consistently. Timing problems don't produce a constant difference; they produce a difference that disappears.

They differ only on some dates. Look for a date-specific override, a promotion window or a length-of-stay rule that applies to one side and not the other. A gap with edges is a rule, not a delay.

They differ in a way that flips direction over time. That's a currency conversion moving with the market, which is a different article and a different fix.

The rule underneath all four: don't change a rate you can't explain. An edit made to close a gap you haven't named becomes a second unexplained gap, and you'll be reconciling both next week.

Source status and the last update

A status describes a position, not a verdict. It tells you where your change sits in the channel's process, and the useful distinction is between three positions: received, applied and stopped.

Received means the channel has the change and hasn't published it. Nothing is wrong yet. Editing again at this point is the single most common self-inflicted problem in this whole sequence. A second edit can overtake the first and leave you with a rate you didn't intend and no clear record of which message produced it.

Applied means the channel published it. If the source price still disagrees after that, you're looking at a data question — a different plan than you think, a tax basis, a currency — and time won't fix it.

Stopped means the channel didn't take it, and the status usually says at which step. That's the one position worth acting on immediately, and the action is to read the step rather than to resend blindly.

The last-update timestamp is the third field, and hosts skip it. Without it, you can't tell whether the status you're reading is from your change ten minutes ago or from one made on Tuesday. Write the time down whenever you read the status, because the next update will overwrite the page and leave you with an impression instead of a record.

What to do while it lags

The first discipline is to stop editing. One change in flight is a state you can reason about; three changes in flight is a guess about which one will win.

The second is to weigh the two risks differently. A lagging channel showing a price below your intended rate is the expensive direction: bookings arrive at a number you didn't choose, and honouring them is usually the right call. A lagging channel showing a price above your intended rate costs bookings quietly. Both matter, but only one of them costs money per reservation.

The third is to choose a holding action that doesn't add messages. If the gap is in the costly direction and the dates are close, closing availability on those specific dates is a decision you can reverse. It's blunter than a rate change and it doesn't compete with the change already in flight.

The fourth is to escalate with evidence rather than with adjectives. A screenshot of the two fields, the timestamp, the value you set and the value the channel reports is a case someone can act on. "It's not syncing" is not.

One detail that causes false alarms at the end of a day: a lag that crosses midnight is easy to misread, because the date you set and the date the channel reports may not sit in the same time zone. Compare the rows by what they contain — a Friday night, a rate for two guests — rather than by the label on the row.

FAQ

Why is only one channel behind?

Each channel runs its own process, and they don't move in step. One being slower doesn't make the others correct — which is why the comparison that matters is each channel against your own rate, not each channel against its neighbours.

If the source price matches my rate, is the calendar fine?

Not necessarily. A matching price means the two sides agree on the number. It says nothing about availability, minimum stay or a closed date, and those can be wrong while the price looks perfect.

Should I keep editing until the number matches?

No. Repeated edits stack messages, and the one that lands may not be the one you meant. Make one change, record it, wait for the status to settle, then read the price again before you decide anything else.

A lag resolves into one of two things: a number that catches up, or a question you can finally ask precisely. Both are better than the third outcome, which is a rate changed three times on a Friday night. And if reading two fields per channel is the part you'd rather not do by hand, localsbnb.com puts the source price and source status next to the dates for every connected channel. The odd one out shows up before it costs a booking.

---

This article is general guidance for hosts and isn't legal, tax or insurance advice. How each channel reports a rate, applies a change and displays a status sits in its own terms and can change. Confirm the current terms of each channel you sell on, and the tax and currency treatment that applies to you, before you act on a difference.