1. OTA rate sync sends prices and selling rules from a hotel PMS or channel manager to each connected booking channel.
2. Derived rates reduce manual work, but the parent rate, calculation rule, rounding, and channel mapping must all be correct.
3. A successful update should be checked at the source, in the delivery log, and on the guest-facing OTA page—especially after peak-date changes.
OTA rate sync through hotel PMS software lets a hotel change a price once and distribute it across Booking.com, Expedia, Agoda, Airbnb, and other connected channels. The same flow can carry minimum stays, stop-sells, and other restrictions.
That does not mean every OTA shows the new rate at the same instant. The PMS creates the update, the channel manager sends it, and each OTA processes it. Mapping errors, conflicting extranet edits, or a delay at any step can leave one channel selling a stale price.
What OTA Rate Sync Actually Updates
Rate synchronization is part of the wider rates, availability, and inventory flow often called ARI. For pricing, the source system sends a rate for a specific property, room type, rate plan, date, and sometimes occupancy.
The source of truth may be the PMS, a revenue management system, or the channel manager itself. Only one system should normally control each field. If the PMS owns BAR while staff also edit BAR in an OTA extranet, the next sync may overwrite the manual change or produce an unexpected result.
A complete rate update can include:
- Nightly price: the amount for one room type, rate plan, date, and occupancy.
- Derived-rate rule: a percentage or fixed adjustment from a parent rate.
- Restrictions: minimum stay, maximum stay, closed to arrival, closed to departure, booking window, or stop-sell.
- Occupancy pricing: different amounts for one, two, or more guests in the same room.
Inventory is related but distinct. A rate can arrive correctly while availability does not, or inventory can be accurate while a child rate still displays yesterday’s price. Diagnose each data type separately.
How One Rate Change Reaches Every Channel
Imagine a 30-room hotel raises its Deluxe King BAR from $180 to $240 for a concert weekend. The revenue manager saves the change for Friday and Saturday in the PMS.
The connected channel manager converts that change into the format each OTA accepts. It sends the property, mapped room and rate identifiers, stay dates, occupancy, currency, and new amount. Each OTA validates the message, updates its sellable product, and returns an acknowledgement or error.
The operational flow should be:
- The manager changes the Deluxe King BAR for the correct stay dates.
- The PMS records the new price and sends the change to the channel manager.
- The channel manager pushes the update to every mapped OTA rate product.
- Each OTA accepts or rejects the message, and the delivery status becomes visible.
- The team checks a guest-facing search to confirm the new price and conditions.
The last step matters because “sent” is not the same as “displayed.” Taxes, fees, mobile discounts, loyalty promotions, or occupancy settings can change the public price after the base rate arrives.
When a peak-date adjustment needs to reach several channels quickly, Smart Order’s hotel channel manager connects the PMS rate change to mapped OTA products. The manager updates the price once, sees the current rates and availability in one dashboard, and can investigate a channel that does not accept the update.
Update Hotel Rates From One Connected Dashboard
Change rates and restrictions once, then keep mapped OTA channels aligned through Smart Order’s PMS and channel manager.
Derived Rates Keep the Price Structure Consistent
A derived rate is calculated from a parent rate instead of being maintained as a separate fixed price. The flexible BAR may be the parent, while non-refundable, advance-purchase, or breakfast rates are children.
If BAR is $200, a non-refundable plan might be BAR minus 10%, producing $180. A breakfast plan might be BAR plus $20, producing $220. Raising BAR to $240 should move those rates to $216 and $260 without separate edits.
The hotel must decide where derivation happens. Some PMS or channel managers calculate child prices and send final amounts to each OTA. Some OTAs support their own parent-child rate relationships. Running both methods on the same product can apply a discount twice.
Check four details for every derived plan: the correct parent, percentage or fixed adjustment, rounding rule, and applicable room types. Also confirm whether the adjustment is calculated before or after occupancy supplements.
Derived pricing does not automatically copy cancellation policies, meal plans, or booking windows. Those conditions may still need separate configuration and mapping. A correct $180 price can remain the wrong product if the OTA shows free cancellation for a non-refundable rate.
Restrictions Must Travel With the Price
A hotel rate is sellable only when its restrictions allow the guest’s search. Updating price without the associated controls can expose an offer on dates when the hotel meant to close it.
Minimum length of stay is a common example. A property may raise Saturday to $300 and require a two-night stay. If the rate update succeeds but the minimum-stay message fails, guests may still book Saturday alone.
Closed-to-arrival and closed-to-departure rules are different from a stop-sell. Closed to arrival blocks check-in on a date but can allow an existing stay to pass through it. Closed to departure blocks checkout. A stop-sell closes the rate plan for sale on the affected date.
Not every OTA supports every restriction in the same way. Some rules apply at room level, others at rate-plan level. The channel mapping should document which system controls each rule and how the connected OTA interprets it.
After changing a high-impact restriction, search several stay patterns. Test a one-night arrival, a multi-night stay crossing the restricted date, and different arrival dates. A single calendar view may not reveal how the OTA applies the rule to a real search.
Why OTA Rate Sync Delays Happen
“Real-time” describes an event-driven connection, not a guarantee that every public page changes in zero seconds. A rate update moves through several systems, and each can queue, validate, retry, or reject it.
A short delay can come from message processing at the PMS, channel manager, or OTA. Larger gaps often point to a failed credential, an expired connection, an unmapped rate, an invalid date range, a currency issue, or a price outside the OTA’s permitted limits.
Bulk changes can also take longer than a single-date update. Repricing 365 days across ten room-and-rate combinations creates far more messages than changing one weekend. Some systems send only changed dates, while others replace a wider range.
Manual OTA promotions create another source of apparent mismatch. A base rate of $200 may sync correctly, but a mobile deal reduces the guest-facing price to $180. Before treating that as a failure, separate the hotel-supplied base rate from OTA-funded or property-funded discounts.
For urgent changes, do not keep resending the same update without checking its status. Repeated full-range pushes can create a longer queue. Review the last accepted value, message timestamp, affected rate ID, and any error response first.
A Practical Rate-Sync Verification Routine
Daily spot checks should focus on dates where a stale price would be costly: near sell-out, local events, new promotions, restriction changes, and the edge of the booking window.
Record the expected base rate, derived rate, restriction, and public result for two or three sample dates. Compare the PMS or pricing source, channel-manager delivery log, OTA extranet, and guest-facing search.
Use the OTA’s displayed currency and occupancy. A two-guest price cannot be compared reliably with a one-guest base rate. Include taxes and fees consistently, and note whether the public result is per night or for the whole stay.
If one channel is wrong, avoid changing every channel. Confirm the room and rate mapping, then isolate whether the error affects the parent rate, one child rate, one restriction, or one occupancy level. A narrow resend is safer than overwriting a year of correct data.
Escalate with evidence. Include the property ID, room and rate IDs, stay dates, expected value, displayed value, update timestamp, acknowledgement, error text, and screenshots. This gives the PMS provider or OTA enough detail to trace the message.
FAQ
How quickly should hotel rates update on OTAs?
Connected systems usually send changes as soon as they are saved, but public display time varies by channel and update size. Verify urgent changes on the guest-facing page and investigate if the delivery log shows an error or no acknowledgement.
Why is an OTA price different from the PMS rate?
The cause may be a failed sync, wrong mapping, occupancy pricing, currency conversion, taxes, an OTA promotion, or a manual extranet override. Compare the same room, rate plan, dates, occupancy, currency, and inclusions before diagnosing the mismatch.
What is the difference between a base rate and a derived rate?
A base or parent rate is maintained directly. A derived rate is calculated from that parent using a percentage or fixed adjustment, such as BAR minus 10% for a non-refundable offer.
Do minimum-stay rules sync with hotel rates?
They can, when the OTA connection supports the restriction and the room-rate mapping is correct. Price and restriction messages may succeed or fail independently, so test the rule with an actual guest search.
Should hotel staff edit prices directly in OTA extranets?
Avoid routine extranet edits when the PMS or channel manager is the source of truth. A manual value may be overwritten by the next sync or conflict with a derived-rate rule. Use the extranet only for settings intentionally controlled there.
Keep the Pricing Source Clear
Consistent OTA pricing depends on ownership. Define where BAR changes, where child rates derive, where restrictions are controlled, and which promotions remain inside each OTA.
Then verify the full path rather than trusting one green status: source value, outbound message, OTA acknowledgement, and guest-facing result. That routine keeps rate sync useful without confusing a processing delay, promotion, or mapping error for a pricing decision.
