A hotel contract can have the right nightly rate and still produce the wrong booking price. The difference may sit in a child age band, an arrival restriction or a supplement that applies only to part of the stay. Hotel contracting software needs to carry those details into the sale. Your loading process has to check that it does.

Start with one representative contract before importing a season's worth of rates. Choose a document containing the awkward rules your team deals with regularly, then agree the expected answers with the colleague responsible for it. Keep a copy of the source and its amendments together. That gives you something reliable to check when a test result looks odd.

Separate the rate from the conditions

Read the contract in terms of what is being priced. Establish whether a figure applies per room, per person or per unit, and whether it is nightly or covers a whole stay. Check currency and any taxes or charges whose treatment is specified in the agreement. If the document is unclear, get the supplier to clarify it before turning the assumption into a loaded rate.

Season dates need equal care. A stay that crosses a rate change is a useful test because it exposes whether the system prices each night or applies another rule. Use the contract's own basis when calculating the expected amount. Don't rely on a plausible-looking total as evidence that the calculation is correct.

For a fictional example, suppose a sample agreement charges £100 per room per night for the first two nights and £120 for the next two. Four nights cost £440 before any other charges. This is deliberately simple test data, not a supplier offer. If that result fails, pause before moving on to complicated discounts or supplements.

Room names need rules behind them

A room label doesn't tell the system how many people it can accommodate or how each person should be charged. Map the contracted room type to the room you intend to sell, including maximum occupancy and the relevant child ages. Check whether an extra bed is included, optional or unavailable. Each detail affects what the customer can safely select.

Use boundary cases in testing. If a child rate ends at a particular age, price a party immediately either side of that boundary using the contract's age rule. Try a room at maximum occupancy and then a party that exceeds it. You want an understandable refusal or a valid alternative, rather than a price for a room the supplier cannot provide.

Board and supplements deserve separate attention. A charge might apply per person, per night or on a particular date, and an optional upgrade is different from a compulsory extra. Work through the amount independently before accepting the screen total. Ask how the condition appears in both the customer-facing description and the booking record.

Test restrictions and stock alongside prices

Have the software supplier demonstrate the contract rules you need, including minimum stays or permitted arrival days where relevant. Test a booking that should pass and another that should fail. A system that returns the expected price hasn't necessarily applied the selling restriction. Keep both results in the review record.

Availability also needs its own checks. Agree how allocations, release periods and stop-sales will be maintained for your contracts, then test changes in a safe environment. Find out who can make each change and how staff see its effect. Don't assume every contracting product supports every rule in the same way.

Open Destinations' Travel Studio describes a contracting module for directly contracted product with rules, currencies and terms. Luna Contracting describes loading through manual entry, a supplier document scan or a spreadsheet, followed by checks before activation. Those are two named approaches to investigate. Neither description replaces a demonstration with the contract you intend to load.

Treat imported data as work to review

Scanning a document can reduce retyping, but your team still needs to compare the result with the agreement. Check every rate basis and restriction that affects a test booking, rather than reviewing only the first row. If a field is missing or ambiguous, resolve it with the supplier or implementation team. Leaving a blank unexplained can be just as troublesome as entering a wrong number.

Give amendments a clear owner. When a hotel sends a revised rate sheet, record what changed and whether the new terms apply to existing bookings or future sales only. That answer comes from the agreement, not from whichever value was most recently typed. Preserve enough history for a colleague to understand the decision later.

Follow the result into the selling channel

Run the approved test through the website or agent selling screen as well as the contract loader. Check the displayed room, price and conditions against your expected result. Then inspect the proposed confirmation and voucher so the information survives beyond checkout. For Travelgenix users, include the resulting Travelify record in that review.

Keep your fictional test cases separate from live inventory and repeat them after material configuration changes. The accompanying sample worksheet provides a starting point for recording expected and observed results; it isn't a live contract or proof of a product feature. Take one awkward agreement to your next supplier demonstration and ask the team to price it with you, rule by rule.

Download the contract test worksheet