Defining a hotel rate as a single number quickly causes problems once sales begin. The same Deluxe room can become different products through flexible, non-refundable, breakfast-included, room-only, single-occupancy or double-occupancy options. If the cancellation terms, payment timing, occupancy price, meal entitlement and sales restrictions of these products are mixed together, the guest may see one offer, the front desk may apply another amount and the channel manager may update the wrong rate. A sound rate-plan structure defines the room type, pricing logic and booking terms in separate layers, then maps them into one sellable product.

What you will learn in this article
  • A room type represents physical inventory, a rate plan represents the commercial offer, and a roomrate represents the sellable product created by combining the room type, rate plan and conditions.
  • Flexible, non-refundable and package plans should be built in an auditable way with a base plan, derived adjustment, cancellation policy and revenue codes rather than copied numbers.
  • Before a plan is opened on a channel, occupancy pricing, date range, meal, tax, cancellation, restriction and channel mappings must be tested end to end with sample reservations.

Separate room type, rate plan and sellable product

A room type groups physical capacity and features such as Standard, Deluxe or Family Room. A rate plan is a commercial pricing category such as Flexible, Non-refundable or Breakfast Included. Booking.com connectivity documentation defines the combination of room type, rate plan and conditions as a separate 'roomrate' or product. In other words, 'Deluxe + Non-refundable + Breakfast' is a sellable product, not the Deluxe room itself.

This distinction must also be preserved in the PMS. Room-type inventory determines how many physical rooms can be sold, while the rate plan controls how the price is calculated and which conditions apply. Five plans linked to the same room type do not create five separate room inventories. Inventory should be shared at room-type level, while price and sales conditions belong at product level. Otherwise, a sale under one plan can leave another plan open and allow the same room to be sold twice.

  • Physical capacity was kept in the room type and the commercial offer in the rate plan.
  • Room type + rate plan + conditions were mapped as one sellable product.
  • Plans linked to the same room type consumed the shared inventory.
  • PMS and channel IDs were stored separately in the mapping table.

Create a small set of base plans and link derived plans

Creating an independent price table for every campaign and channel is easy on day one but risky to maintain. The base flexible plan carries the core price for room types and dates. A non-refundable plan can be derived by a percentage or fixed adjustment from the base price, while a breakfast plan can add a per-person package amount. Oracle OPERA Cloud documentation explains that changes to a base rate's calendar can automatically affect derived rate codes. Booking.com also supports child-rate relationships that follow a parent plan in a defined way.

It must be clear which elements a derived plan follows: price, open/closed status and restrictions are not the same. For example, a Non-refundable plan may be priced 10% below the Flexible plan while using a different cancellation policy. If a child plan follows only the price and not the restrictions, a minimum-stay change must be sent separately. The system should present the relationship in a readable form such as 'BAR - 10%; follows price, does not follow restrictions.'

  • A limited set of base plans was defined for core pricing.
  • The derived plan's fixed or percentage adjustment was recorded.
  • Price, restriction and open/closed inheritance were defined separately.
  • Child plans affected by a base-plan change were shown in advance.

Connect occupancy and child ages to the pricing model

Channel comparisons are unreliable unless it is clear whether the displayed room price is for one guest, two guests or maximum occupancy. Booking.com defines several pricing types, including Standard, Rate-Level Occupancy, Occupancy-Based Pricing and Length of Stay. The selected model must match both the channel's technical support and the hotel's sales logic. If the PMS stores single, double, extra-adult and child prices separately, the channel mapping must support those levels correctly.

A 'children stay free' option alone is not enough for child pricing. Age bands, the number of free children, extra beds and whether the child stays with an adult or in a separate room can change the price. Oracle OPERA Cloud handles child age groups and extra-child amounts separately in the pricing schedule. When an age changes on a reservation, the price should be recalculated; the old total should not be silently retained and the new amount should not be charged without confirmation.

  • The plan's base occupancy and maximum occupancy were clearly defined.
  • Single occupancy, extra-adult and child adjustments were tested separately.
  • Child age bands had the same meaning in the PMS and on the channel.
  • The price was recalculated and shown to the user when occupancy or age changed.

Make cancellation, prepayment and no-show terms part of the plan

The difference between flexible and non-refundable plans is not just the price. The cancellation deadline, penalty amount, prepayment timing, guarantee condition and no-show charge form the commercial terms of the reservation. According to the Booking.com Policies API documentation, a cancellation policy is defined at property level and assigned to the product at roomrate level. Because a product without an assigned policy can inherit the default policy, a mapping error may go on sale without being obvious.

The PMS should store the actual rules, not just the policy name. A 'Non-refundable' label alone does not explain when payment will be collected or what amount will be charged for a no-show. When a policy is updated, existing reservations should retain their original terms while new sales use the current version. The reservation record should store the policy ID together with the readable text and penalty summary shown at the time of sale.

  • Cancellation deadline, penalty, prepayment and no-show were defined in separate fields.
  • The correct policy ID was assigned to every sellable product.
  • Tests confirmed that the default policy was not applied by mistake.
  • The policy version at the time of sale was stored as an immutable reservation record.

Configure meals and packages so revenue is allocated correctly

A breakfast-included plan is more than a note added to the room price. You must define whether breakfast is priced per person or per room, whether it applies to children, on which days the entitlement is created and how an unused entitlement is accounted for. Oracle OPERA Cloud package documentation shows that room, food-and-beverage and other package elements can be tracked with separate transaction codes, defined posting frequencies and, when needed, a package ledger.

If a package amount disappears entirely into room revenue, departmental revenue, tax and performance reports can be distorted. Room-only, room-and-breakfast and half-board plans allocate revenue differently even when they show the same total price. For each package, define the included service, calculation rule, tax-inclusive or tax-exclusive status, sales revenue code and posting time. The channel description must also reflect the actual entitlement in the PMS.

  • Meal type and the per-person or per-room calculation rule were defined.
  • Package elements were linked to the appropriate revenue and tax codes.
  • Posting time was defined as arrival, every night or departure.
  • Included services shown on the channel were compared with entitlements in the PMS.

Manage season, day and sale dates without conflicts

Stay dates and sale dates must not be confused in a pricing schedule. A summer price may apply to stays from 1 June to 30 September, while an early-booking plan may be sold only until 31 March. Day of week, room type and occupancy can also change the price in the same schedule. Oracle OPERA Cloud pricing schedules allow start and end dates, days of week, room type and adult/child amounts to be defined together.

When two schedules overlap for the same room type and plan, it must be clear which price wins. The system should either prevent the conflict or show the priority rule. A date with no price must not remain open for sale. Boundary dates need particular testing when a new season is added: whether the end date is inclusive, the time zone at midnight and the channel's interpretation of date ranges can create a pricing gap or a one-day pricing error.

  • Stay validity and the booking window were defined separately.
  • Schedules by date, day of week and room type passed conflict checks.
  • An open date without a price was prevented.
  • Season start and end dates were verified with a sample query in the channel calendar.

Apply a small, purposeful set of restrictions

Minimum stay, maximum stay, closed to arrival, closed to departure and advance-booking time determine whether a rate plan can be sold. Booking.com documentation notes that several restrictions can overlap on a date or date range and that the API does not always return an error or warning for conflicting restrictions. A 'rate sent' response therefore does not mean the product can actually be found in a search.

Every restriction should serve a specific revenue objective. Requiring two nights for a busy Saturday is not the same as applying a two-night minimum to the entire week. A restriction change should log the old value, new value, user, channel, date range and reason. After publication, test searches should cover one-night and two-night stays with different arrival days, and products closed by mistake should appear in an alert panel.

  • The restriction was shown clearly at room-type, rate-plan and date level.
  • Overlapping minimum-stay and closed-date rules were tested together.
  • The result was verified with a real sales search even after a successful update.
  • Restriction changes were written to the audit history with the user and reason.

Complete channel mapping and go-live checks

The PMS rate code and the channel's rate-plan ID are not the same. For every room-type and rate-plan product, map the channel ID, currency, occupancy pricing model, cancellation policy and meal code. Google Hotel Prices ARI documentation also handles rates and availability at product level, where the product is the combination of room type and rate plan. If a channel does not support a feature, the system should warn the user instead of silently sending an approximate value.

A go-live check must not end with a technical 'success' response. Run live searches for at least one weekday, one weekend, single occupancy, double occupancy, a stay with children, and flexible and non-refundable plans. Compare the displayed total price, tax, meal, cancellation text and availability with the PMS. Then import a test reservation into the PMS and check the price breakdown and policy record. Repeat this checklist for every new plan, season or channel mapping.

  • PMS and channel product IDs were kept in a unique mapping table.
  • Currency, occupancy model, meal and cancellation policy were validated for each channel.
  • The total price and conditions were compared in a live search.
  • A test reservation was imported into the PMS and its folio and policy breakdown were checked.
Short answers

FAQ

What is the difference between a rate plan and a room type?

The room type defines the physical room category and capacity, while the rate plan defines the price and commercial terms category. In channel sales, combining the room type and rate plan with cancellation, meal and booking rules creates the sellable product.

Should a non-refundable rate be derived automatically from the flexible rate?

It simplifies maintenance for many properties, but cancellation, prepayment, no-show and booking-window rules must be defined separately from the price adjustment. It must be clear whether the plan follows the base plan's price, restrictions or open/closed status.

Is a plan ready for sale when the channel manager sends its rate successfully?

Not always. Overlapping restrictions, an incorrect occupancy model, a default cancellation policy or a missing meal mapping can be technically accepted yet display the wrong product. Verify the flow end to end with a live search and a test reservation.

Sources and updates

Operational recommendations should be adapted to the property's own conditions. Information about PMS and channel operations was checked against the official documents below on 24 September 2026.