---
title: "Hotel Rate Plans and Pricing Models Explained"
description: "Learn how rate plans, occupancy pricing, length-of-stay pricing, restrictions and derived rates interact inside hotel distribution and metasearch systems."
slug: "rate-plans-pricing-models"
translationKey: "learn-rate-plans-pricing-models"
locale: "en"
type: "guide"
category: "pricing"
tags: ["rate-plan","pricing","occupancy","los","hotel","distribution"]
publishedAt: "2026-09-20"
updatedAt: "2026-09-20"
reviewedAt: "2026-09-20"
sources:
  - title: "Booking.com Understanding pricing types"
    url: "https://developers.booking.com/connectivity/docs/understanding-pricing-types"
  - title: "Booking.com Configuring and Retrieving Pricing Types"
    url: "https://developers.booking.com/connectivity/docs/configuring-retrieving-pricing-types"
  - title: "Google Hotels Pricing overview"
    url: "https://developers.google.com/hotels/hotel-prices/dev-guide/updating-prices"
---
A hotel rate plan is not just a price label. It combines pricing logic with conditions such as occupancy, cancellation, meal, sales restrictions and sometimes market eligibility. Metasearch systems must preserve those semantics or they end up comparing non-equivalent products.

## A rate plan is a commercial contract for an offer

Two offers for the same room can represent materially different products. One can be refundable with breakfast, while another is non-refundable and room-only. A useful rate-plan model therefore includes both the monetary amount and the rules that explain why that amount exists.

This is why “room + price” is too small a data model for hotel comparison.

## Pricing type changes the meaning of the number

Booking.com documents multiple pricing approaches including Standard, derived pricing, Occupancy-Based Pricing and Length Of Stay pricing. The important lesson is not the vendor-specific names; it is that a price can depend on occupancy and stay duration rather than only room and date.

A normalization layer should therefore know whether the supplier amount is:

- room-based,
- occupancy-based,
- guest-based,
- length-of-stay-based,
- derived from a parent rate,
- promotional or conditional.

## Occupancy is part of product identity

A double room priced for one adult may not be comparable with the same room priced for two adults. If a supplier returns occupancy-specific rates, collapsing them into a single “lowest room price” loses information and may create a misleading comparison.

Use a normalized occupancy structure with adults, children, child ages where required and room count.

## Length of stay can change both price and availability

LOS pricing means the total economics of the stay cannot always be reconstructed by multiplying a one-night price. Minimum-stay rules, stay-level discounts and length-dependent prices can all produce different totals.

For this reason, metasearch price keys should include itinerary dimensions such as check-in and number of nights.

## Derived rates need lineage

A child rate can be calculated from a parent rate using percentage or fixed adjustments. When systems only store the final numeric value, they lose the reason behind the rate and make reconciliation harder.

Useful fields include:

- parent rate-plan ID,
- derivation rule,
- discount/markup type,
- effective dates,
- eligibility conditions.

## Restrictions belong with the rate plan

Typical rules include cancellation policy, meal inclusion, advance purchase, minimum stay, member-only eligibility and market conditions. Some platforms also support conditional or fenced rates.

The comparison UI should not hide these differences behind one price sort.

## Normalize for comparison, preserve for booking

A good architecture creates a normalized comparison shape but also preserves the original supplier payload or key identifiers needed for booking. The normalized model powers sorting and filtering; the supplier-specific identifiers preserve booking correctness.

The design goal is not to erase supplier differences but to make them understandable.

## Meta Search takeaway

Rate plans are multidimensional commercial products. Price, occupancy, stay length, cancellation, meal and eligibility form one offer contract. Metasearch quality improves when normalization compares like with like while still retaining the supplier semantics required for handoff and booking.

## How should rate-plan lineage be stored?

If a derived or child rate is stored only as a final amount, the reason for the price is lost.

```text
rate_plan_id
parent_rate_plan_id
pricing_type
derivation_type
derivation_value
meal
cancellation_policy
payment_timing
eligibility
effective_from/to
```

This lineage helps reconciliation and promotion debugging.

## Why is flattening pricing models risky?

Forcing occupancy- or LOS-based pricing into a nightly room amount can destroy source semantics.

Example three-night package:

```text
night 1 = 100
night 2 = 80
night 3 = 0 promotional
total   = 180
```

Displaying “60/night” may aid comparison, but the original pricing basis should remain available.

## Common failure modes

- child rate misses parent update,
- occupancy price applied to wrong guest count,
- LOS discount lost during nightly flattening,
- promotion eligibility exposed publicly,
- cancellation policy detached from the rate plan.

## KPIs

- rate-plan mapping coverage,
- derived-rate calculation mismatch,
- occupancy-pricing error,
- promotion mismatch,
- stale rate-plan age,
- booking rejection by pricing-rule reason.

A rate plan is not a number; it is **price + eligibility + policy + lineage**.