Derived Rate

Why it matters

Pricing concepts only make sense with occupancy, stay, cancellation, tax/fee and eligibility context. Normalizing one numeric amount is easy; deciding whether two products are truly comparable is harder. Pricing semantics should remain consistent across display, ranking and booking handoff to avoid false parity and accuracy conclusions.

What does it look like in practice?

A €200 breakfast-refundable offer and a €192 room-only non-refundable offer may look close numerically but are not the same product. Pricing concepts need occupancy, rate-plan and tax/fee context.

Implementation questions

• Is the amount nightly or stay-total?
• Are mandatory taxes and fees included?
• Which occupancy and rate plan does it represent?
• Does it require revalidation before booking?

Common mistakes

• Confusing base and total price
• Dropping eligibility rules
• Treating different room/rate semantics as equivalent

Where does it appear in the travel stack?

Derived Rate commonly appears across pricing layers. Its implementation should make source-of-truth, identity, freshness and transaction-ownership boundaries explicit.

Related terms