Contract loading checklist: putting agency rates into your systems correctly

Hotel contract loading is the step that turns a signed agency contract into bookable rates in your hotel system and in the agency's system. It is done correctly when both sides quote the same price on the same test date, for every season, room type, board basis and child band the contract covers.

The agency's invoice arrives in November and disagrees with your records by a small amount on a handful of reservations. Nobody is lying. Somewhere in the spring, a season boundary went in one day early, or a supplement written per room was typed in as per person, and every booking since has carried the difference. This article walks the whole path from signed contract to loaded rate: which documents you need, how each clause maps into a system field, how to verify the load with a second person, and how to keep amendments under control.

What is hotel contract loading, and why do the errors stay hidden?#

Contract loading is the act of copying the commercial terms of a signed agency contract into the systems that quote, confirm and bill rooms. The errors stay hidden because a wrongly loaded rate is still a working rate: nothing breaks, it simply quotes the wrong number.

Three copies of the same agreement exist: the signed contract, your hotel system (the property management system, or PMS, the record of rooms, rates and guest bills), and the agency's own reservation system. The contract is the source; the other two are copies, and every difference between copies is a future argument. A wrong season boundary, a missing stop-sale right or a mis-keyed child band produces no error message. The system confirms the booking and the guest arrives.

Errors surface at three moments: at the front desk when the guest shows a confirmation at a different price, at the agency when its availability does not match yours, and at the invoice, often months after the stay. The cost is not only the money. It is the time spent reconstructing what was agreed, and the contract usually settles it in one line that nobody read at load time.

Loading is a named job with an owner, not something squeezed between check-ins. If no one owns it, the person who loads is also the person who decides ambiguities, and that is where errors enter.

Which documents must be in force before you load anything?#

The executed contract, every annex it refers to, and a written list of the special promotional offers in force on the load date. If any of the three is missing, the load waits.

Identify the executed version: signature pages, initials on each annex, and the date the agreement took effect. Contracts are often sent back and forth; only one version is signed. The numbers usually live in the annexes, not the body: the rate grid, the room-type list, the child policy, the release table and the stop-sale terms. A missing annex is a missing rate.

Special promotional offers (SPOs, discounted rates agreed on top of the contract for a limited period) need their own list with start and end dates. This is industry usage; there is no official definition to cite, so write the contract's own wording into the rate note rather than a shorthand of your own.

Confirm the money basis before typing: net or commissionable, per room per night or per person per night, and whether tax is included. A rate loaded on the wrong basis is wrong by a fixed percentage on every booking. When you state net rates, the same discipline applies to how the quote shows its working, as covered in hotel net rates for travel agents.

Ask the agency contact for one written confirmation that the annex list is complete and current, and keep it in the contract file next to the signed pages. If a clause is ambiguous, stop. Get the clarification in writing before loading; a decision made at the keyboard has no author and no defence later.

How do periods, room types, board and occupancy map into the system?#

Each contract element becomes a specific field, and each field has one classic error. Check the field, not the general impression that the rate "looks right".

Season boundaries: a contract written as 01.05 to 31.10 inclusive must produce a price change on exactly those dates. Many systems store an end date that is exclusive, so check one night on each side of every boundary. Room-type mapping: the contract's room name must map to the exact room type the agency sells and the exact code your PMS holds. A mapping one level off sells a sea-view room at the standard price without any warning; the same risk exists when connecting external channels, as discussed in channel manager mapping and testing.

Board basis: room only, bed and breakfast, half board and all inclusive are industry usage with no official definition, so record the contract's own inclusion list in the rate plan note rather than assuming what "half board" covers. Occupancy: base occupancy (how many people the rate covers), maximum occupancy, and the extra-bed price with its basis, per person per night or per bed per night.

Build a rate plan code that states agency, period, board and currency, so a human scanning a list can spot the wrong one. Codes like "RATE1" hide errors. If the contract is in a foreign currency and the system quotes in lira, agree and record the conversion rule, because a rounding difference repeated across a season is a real number.

How do supplements, reductions and child bands go wrong?#

Almost always through the basis: the contract says per room and the system charges per person, or the contract gives an age band and the system treats the child as an adult. The number is right; the multiplier is wrong.

Child bands: record the age ranges, what applies in each (free in the parents' room, a reduced rate, adult rate from a stated age), and whether age is counted at arrival or at booking. The contract usually says; if it does not, ask. Reductions have a base: a third-bed reduction, a single-occupancy reduction and a no-meal reduction are each a percentage or an amount taken off something specific. Write down what that something is before loading.

Percentage rules hide the same trap: 50% off the double rate, off the per-person rate and off the adult rate in that room are three different numbers. Load the one the contract names. Limits per room, such as "one child free per room", are rules the system must enforce, not notes in a document nobody opens at the desk.

Test the arithmetic both ways: price the same family as the contract's own worked example, if it has one, and as your system quotes it. If the two differ, the load is wrong, not the example.

How do you load release periods, stop-sale rights and allotment sizes?#

As three separate records, each with its own field and its own test. Allotment is how many rooms the agency holds, release is when unsold rooms come back, and stop-sale is whether you may close dates to the agency at all.

Allotment and release are industry usage rather than defined terms, so load the contract's numbers, not a house habit; the release periods and allotment clauses worth checking deserve their own read before you load them. Load allotment by room type and by period, not as one number for the season. A single seasonal figure is wrong for most of the year.

Two failure modes on release: set shorter than the contract and rooms return too late to sell; set longer and the agency loses rooms it had a right to hold. Both create disputes that the contract settles against whoever loaded it. Stop-sale right: whether the hotel may close dates to this agency, and on what notice. If your system has no field for it, the right exists on paper only and the front desk will discover it during a full week.

Know which of the three confirmation behaviors this contract is: fixed allotment, free sale (the agency sells against live availability) or on request (each booking is confirmed by a person). The system must be set to the one the contract names. Finally, check the release rule against a real date: pick an arrival date, count back the release days, and confirm the system returns the room to general availability on exactly that day.

How do you verify a load with a four-eyes check?#

One person loads, a second person compares sample prices against the contract and signs a test sheet. The load is finished when the sheet is signed, not when the data is in.

Choose test dates deliberately: the first day of each season, the day before and the day after every boundary, one date inside each special promotional offer, one date outside it, and one peak date. For each test date, calculate the expected price by hand from the contract, then read what the system quotes. Compare the two numbers, not the two screens.

Check what the agency would see, not only your internal screen. A load can be correct internally and wrong in what is published outward. Test more than a double room: a single, a triple, an extra bed, and a child in each age band the contract defines. The checker must be able to read the contract, not just the screen; a second pair of eyes on the same misreading is not a check.

Record the sheet with date, tester, contract version, test dates, expected and actual prices, and the result. Keep it in the contract file.

How do you keep amendments, SPOs and versions under control, and match invoices later?#

Every change follows the same path as the original load: written amendment, load, second-person check, one line in the version log. That log is what lets you rebuild an agency invoice from the file months later.

An amendment is not a conversation. It is a written change with an effective date, loaded and checked like the original. The version log records what changed, who asked for it, who approved it, when it was loaded, into which system, and from which date it applies. One line per change, kept with the contract.

Special promotional offers get their own code and their own start and end dates. Never overwrite a base rate with an offer rate; when the offer ends, the base rate must still be there. Know how to undo a load before you perform it. If a wrong rate has been published outward, the correction is a second load, and the log must show both.

Invoice matching: an agency invoice should be reconstructible from the loaded contract and the reservations. When a line cannot be rebuilt, the difference is either a load error or a booking made outside the contract, and the two need different answers. The mechanics of matching agency invoices to the contract you loaded follow directly from this file. Review it once a season against the reservations actually received, so a systematic difference is found by you rather than by the agency's accounts department.

What to do next#

Pick one agency contract already in force, pull its signed pages and annexes, and run the test sheet against it this week: four test dates, one child band, one supplement, one release date. Whatever the sheet exposes is the real state of your contracting, and it is cheaper to find now than on an invoice in November.