Too many rate codes: a clean-up checklist for your rate plans
A hotel rate code clean up requires exporting every code, counting bookings, and grouping by purpose. Learn how to close unused codes safely and fix channel mapping.
Contents
Key takeaways
- A rate code carries three things at once, a price, a set of conditions and a distribution permission, so a code nobody books can still put a wrong price in front of a guest.
- Closing a code is not deleting it: past bookings, invoices and reports keep pointing at it, and only future selling stops.
- Count bookings per code over a fixed window before you judge any code by its name; the code that looks like a test is sometimes the one a corporate account uses.
- A code closed in the hotel system but still mapped in a channel extranet is more dangerous than a code left open, because nobody is watching it.
- The clean-up only holds if one named person approves every new code and every new code is created with an end date.
A rate code is the short label a hotel system uses for one rate plan: a price, the conditions attached to it and the channels where it may be sold. A hotel rate code clean up means exporting every code, counting bookings per code, grouping them by purpose, closing the unused ones without deleting history, and re-checking channel mapping after each change.
Open the rate plan list in your system and sort it by name. Somewhere past the first screen the codes stop describing prices and start describing people: a sales manager who left, a contract that ended, a season that closed. Each one still has a price attached, and some are still mapped to a channel. After reading this you will be able to export the full list, judge each code by evidence rather than name, close the dead ones safely and put rules in place so the list does not grow back.
What is a rate code, and why does a hotel end up with too many?
A rate code is the internal label for one rate plan: a price, the conditions attached to it and the channels where it may be sold. Hotels accumulate them because opening a code is quick and closing one touches contracts, channels and history.
Rate code, rate plan, revenue code: three different things
Three lists get confused in every clean-up. Rate codes describe what the guest bought and under which conditions. Revenue codes are the accounting buckets the money lands in, such as room, food or minibar. Room types are the physical product. A rate clean-up touches only the rate side; the revenue side belongs to accounting and should be left alone.
One code per season, per market, per board type, per contract and per channel adds up fast. A new code is usually the fastest way to answer a request, so it becomes the default answer. Nobody closes them because closing feels risky with open bookings and live contracts, no single person owns the list, and the person who created the code has often moved on.
The four layers inside one code
The cost shows up in mechanisms, not adjectives. A stale code quoted on a channel undercuts the rate the hotel meant to sell. One market segment splits into nine lines in every report. A new receptionist picks the wrong code at the desk.
| Layer | What it holds | What goes wrong in a clean-up |
|---|---|---|
| Price | A base rate or a derivation from a parent rate | A child code left pointing at a retired parent |
| Conditions | Cancellation terms, board, minimum stay, market segment | A condition nobody can explain to a guest at the desk |
| Distribution | Which channels may sell it and how it is mapped | A code closed in the hotel system but still live in an extranet |
| History | Past bookings, invoices and reports | A code deleted instead of closed, leaving gaps in the record |
A clean structure starts from one anchor rate with the rest derived from it, which is a design decision rather than a tidy-up. If you are setting up a system rather than cleaning one, the order of decisions matters, and you can read more about setting up room types, rate codes and revenue codes in the right order. There is no correct number of rate plans. The test is whether every code has a purpose, an owner and an end date.
How do you export the rate list and count bookings per code?
Export every rate code with its name, parent rate, conditions, channels and creation date, then add one column the system will not give you: how many bookings each code took in a fixed window.
Export as a spreadsheet from the system, not a screenshot of a screen, and include inactive and archived codes, because those are the ones that produce surprises. Fix the window before you start, for example the last 24 months, so annual contracts are caught. Write the window and the export date at the top of the file.
Add three columns per code: bookings, room nights and the date of the last booking. The last-booking date is often more useful than the count. Read the shape of the result rather than a single number: many codes with a handful of bookings each points to codes created per request, while a few codes carrying most of the business is normal.
Flag the dangerous group: codes with no bookings in the window but a price still attached and a channel still mapped. Do not judge by name. A code called TEST may be the one a corporate account books on, and a code called CORP may have been dead for two seasons. Keep the dated export as the record of the clean-up, so the next person can see what changed and when.
ChecklistExport checklist
- Every active code listed
- Every inactive and archived code listed
- Parent rate shown for each derived code
- Conditions column present
- Channel mapping column present
- Creation date present
- Bookings, room nights and last-booking date added
- Window and export date written at the top
- File saved with a date in its name and stored where the team can find it
How should you group rate codes by purpose, and what naming rule stops the mess returning?
Group by what the code is for, not by who asked for it: a public anchor rate, derived rates for board and length of stay, contracted or negotiated rates, and internal codes that must never be sellable.
Put every code in exactly one of four groups: the public anchor and its derivations; board and package rates; contracted rates for companies, agencies and tour operators; and internal codes such as house use, staff, complimentary and testing. Force internal codes into a non-sellable state and unmap them from every channel. A house-use code that can be booked online is a pricing incident waiting to happen.
A naming rule you can enforce
Set a naming rule with a fixed field order: market, then board, then condition, then channel. A code can then be read left to right without opening it. Ban personal names, dates and season words inside the name, because they expire silently and nobody notices when they stop being true. Keep the end date in a field of its own, not in the name, so the system can show you what has expired.
TipA name you can read without opening the code
Use the field order market, board, condition, channel. For example, a well-formed name might be CORP-BB-STAY3-DIRECT for a corporate rate with breakfast, three-night minimum, direct channel, or LEIS-RO-FLEX-OTA for a leisure room-only flexible rate sold on an online travel site. A badly formed name would be SusansRate2019: it names a person, a year, and nothing about the product. The end date lives in a field, never in the name.
Derived rates inherit from a parent, so grouping is also a decision about which rate is the anchor and which ones follow it. The approach follows the same logic as building a rate structure from a best available rate with derived rates. Apply the test: if a code cannot be named under the rule, it usually should not exist.
What must you check before you close a rate code?
Before a code is closed, check three things: open and future bookings on it, contracts that still name it, and every channel where it is mapped.
Open and future bookings come first. Confirm in your own system that closing the code leaves existing reservations, their prices and their conditions untouched. Contracts come second: a corporate or agency agreement may name the code, and closing it can break a rate the hotel has promised for the rest of the season.
Derived rates need their own pass. Closing a parent freezes or breaks its children, so close or re-parent the children first and check the parent last. Packages and inclusions hide inside codes too: a code may be the only place a breakfast, a transfer or a spa credit is defined, and closing it removes the inclusion with the price.
Void, never delete. Closing stops future selling; the history, the invoices and the reports keep pointing at the code, which is exactly what you want when someone asks what was sold last August. Do the batch in a low-activity window, one group at a time, and write down the date and who did it.
Watch outThe closed-but-still-mapped code
The code is switched off in the hotel system, the channel extranet still holds the mapping, and the result is either a rate the hotel cannot honour or a booking that fails the moment a guest tries to make it. The rule: closing in the hotel system and unmapping on the channel are two actions, and both are needed.
Treat the channel side as a separate job with its own check, never as something that happens automatically.
How do you check channel mapping after every change?
Compare the live channel extranet against the hotel system code by code, then run one real booking path on each channel you touched and cancel it.
The mapping is a join: a mapping table pairs a hotel code with a channel code, and a change on either side breaks the pair without an error message. Do the check in the extranet, not in the hotel system, because the extranet is what the guest actually sees. Check the quoted price, not just the presence of the code; a code can be mapped correctly and still carry a price nobody intended.
Run a test or a cancellable booking through the full path, then cancel it and confirm the room returns to inventory. Log the check: date, who did it, which channels, what was quoted, what was corrected. After a batch clean-up, re-check every channel that was mapped to any closed code, not only the channels you think you changed. Repeat the check at the start of each season, because channel extranets change too. The mechanics are the same as those described for channel manager mapping for room types and rate plans, and how to test it.
ChecklistPost-change mapping check
- Closed codes removed from every extranet
- Remaining codes still pointing at the right room type
- Quoted price matches the intended price
- Conditions shown to the guest match the code
- One test booking made and cancelled per channel touched
- Room returned to inventory after cancellation
- Result logged with date and name
Who may open a new rate code, and when is the clean-up done?
One named owner approves every new code through a short written request, and the full clean-up runs on a fixed date once a year, with a short check each season.
Split the permissions: one role creates codes, another maps them to channels, and closing is agreed with the person who owns the contracts. Require a short request for every new code: purpose, market, conditions, channels, end date and who asked for it. Make the end date mandatory at creation, because codes created without an end date are how the list grows back.
| Decision | Suggested owner | Check before acting |
|---|---|---|
| Create a new rate code | Revenue manager | Purpose and end date recorded |
| Map a code to a channel | Reservations or channel manager | Price and conditions verified in the extranet |
| Change a price on a live code | Revenue manager | Open bookings and contracts reviewed |
| Close a code | Revenue manager with the contract owner | Future bookings, contracts and channel mapping cleared |
Place this rule next to your discount and override limits, the same territory covered in who may change a rate, and the discount limits that go with it, so the same person cannot invent a code and set its price without a second pair of eyes.
A yearly date, not a yearly intention
Choose the annual date deliberately: after the season closes and before next year's contracts are signed, in a fixed month rather than when someone has time. Add a short quarterly look at only the codes created since the last check, which takes minutes and prevents the annual job from becoming large again. Measure success by the absence of surprises, not by a shorter list: every code live on a channel should be one a person can explain.
What to do next
Export the list this week, add the bookings and last-booking columns, and put the annual clean-up date in the calendar before you close anything. The pieces fit in one order: export and count, group and name, check contracts, bookings and channels before closing, verify the mapping afterwards, and keep one rule that decides who may open the next code. The clean-up is not the point; the point is that no code reaches a guest without someone able to explain it.
Frequently asked questions
What is the difference between a rate code and a revenue code?
A rate code describes what the guest bought and under which conditions, including the price, cancellation terms, board and the channels allowed to sell it. A revenue code is the accounting bucket the money lands in, such as room, food or minibar. They are separate lists, and a rate clean-up should not touch the revenue side, which accounting depends on.
Can I delete an old rate code instead of closing it?
Closing is enough and deleting is a bad idea. Past bookings, invoices and reports point at the code, and removing it leaves gaps in the record. Closing stops future selling while the history stays readable, which is the same void-never-delete logic hotels already use for financial records.
How many rate plans should a hotel have?
There is no correct number, and any figure quoted as a norm should be treated with suspicion. The usable test is whether each code has a purpose, an owner and an end date. A code nobody can explain is one too many, whatever the total is.
What happens to future bookings if I close the rate code they are on?
Existing reservations should keep their price and conditions, because closing affects new selling rather than the record. Confirm this in your own system on one code before running a batch, and check that the reservations still show the correct rate after the change.
Does closing a rate code in the hotel system also close it on the channels?
Not necessarily. Channel mapping is a separate pairing between a hotel code and a channel code, and it can survive the closure. Unmap or close the code on the channel side as well, then check the extranet and run a test booking on each channel you touched.