For direct hotel rates, our recommended starting point is a written loading sheet that traces each setting back to the supplier agreement. Record the price separately from the inventory and booking conditions, then test the complete offer. This makes it easier to find whether a problem comes from the contract wording, the loaded setting or the search being tested.

Google’s ARI documentation separates availability, rates and inventory messages and identifies a product through a room-type and rate-plan combination. That is a useful example of why these concepts need distinct records even when the customer sees one offer. Source: Google Hotels: availability, rates and inventory overview

Build a rate record someone else can check

For each offer, record the property and room references, rate-plan name, occupancy, meal basis, currency, applicable dates and pricing basis. Add payment and cancellation terms from the agreement. Assign an owner to any missing or ambiguous detail instead of filling it with an assumed default.

Include the original agreement or an authorised clarification in the working record. If a supplier changes a term, note which version replaced it and which bookings or dates need review. This is our suggested control for keeping a loaded offer traceable to its source.

Separate the release rule from cancellation

Oracle’s hotel block documentation distinguishes a fixed cut-off date from a rolling number of cut-off days before each stay date. The rule governs the release of unreserved rooms in the block. Check which method the agreement uses before choosing a setting. Source: Oracle Hospitality: cut-off dates and cut-off days

Ask separately about the cancellation terms for a room already booked and any financial commitment on unsold rooms. A release setting should not be used as evidence that returning inventory is penalty-free. Read allocation and release period alongside the agreement.

Translate restrictions precisely

Booking.com’s inventory documentation distinguishes stay-length rules from closed-to-arrival and closed-to-departure rules. Some stay rules are arrival-based, while others apply when a stay includes the relevant date. Preserve that scope when translating a supplier instruction into your system. Source: Booking.com: inventory and booking restrictions

Use the glossary to check minimum length of stay, maximum length of stay, closed to arrival and closed to departure. If the booking engine cannot represent the agreed restriction, resolve the gap before putting the offer on sale.

An illustrative restriction test

Suppose an agreement requires three nights for Friday arrivals and closes Saturday arrivals for one rate plan. Test Friday for two nights and Friday for three nights. Then test a Saturday arrival and a stay beginning earlier that crosses Saturday. Write the expected result beside each search before running it.

These are invented conditions for a test exercise. The point is to vary one element at a time so you can see which rule causes a result. Do the same for occupancy, meal basis and any seasonal boundary that applies to the real agreement.

Check the money with a worked calculation

For another illustrative test, assume two nights cost £100 each and a third costs £120, with no other charges in this simplified example. The expected base total is £320. Add only the supplements, fees and other components specified in the actual agreement, then compare the complete expected total with the result returned.

Have a second person review one calculation without using the loaded system as their source. This provides a useful check against reproducing the same loading assumption in both the expected and actual result.

Test before, at and after a boundary

• Seasonal date: check a stay on each side and a stay crossing the change, because the test should expose which rate applies to each night.

• Release deadline: check unused allocation before and after the agreed cut-off, because this verifies the inventory rule rather than only the price.

• Stay restriction: check one night below, exactly at and one night above a limit, because boundary tests expose an incorrectly applied rule.

• Amendment: change the dates of a test booking, because the team needs to know how the revised offer is calculated and recorded.

Using Luna Contracting

The Luna Contracting product page documents net or gross rate entry, seasonal pricing and a search or price-check view for checking loaded offers. Use those views to work through your own agreement and calculations. Ask about any specific restriction you need rather than assuming that a restriction documented by another platform is supported identically. Source: Travelgenix: Luna Contracting pricing and inventory

Keep the approved test record with the contract. It gives the next person a clear starting point when a rate changes or a customer query needs investigating.

Written and updated by Travelgenix. Sources checked on 16 October 2026. Worked examples and checklists are editorial illustrations and recommendations, not customer results.