Setting up a new PMS: room types, rate codes, revenue codes and users in the right order

A property management system (PMS) is configured in dependency order: room types and room numbers first, then rate codes, packages and board types, then revenue and payment codes and taxes with your accountant, then market and source codes, then users, roles and document templates. Each table feeds the next, so copying the old system's lists blindly produces wrong reports for years.

The contract is signed, the cutover night is booked, and the trainer arrives on Monday. Nobody has yet decided who is allowed to say what a revenue code is, and the old system's list is a long one, half of it named after people who have left. This guide gives you the order a PMS implementation plan should follow, the decision behind each configuration table, and who signs it. Data transfer and the cutover night are separate pieces of work, covered in PMS data migration and the cutover checklist.

Why does the order of PMS setup matter?#

Because each configuration table is referenced by the next one: a rate code cannot exist without a room type, a charge cannot be posted without a revenue code, and a report joins all of them. Set them out of order and you either block yourself or build a structure you must rebuild later.

A property management system is the software that holds reservations, rooms, bills and reports. Turkish hoteliers also call it the otel programı, and the formal term is otel yönetim sistemi (PMS). Whatever you call it, the dependency chain runs rooms, then rates, then money codes, then segments and sources, then users and documents. Each step assumes the previous one is settled and signed.

Copying the old system's lists carries its history with it: dead codes, codes renamed after a former manager, and codes that only ever existed because of one contract that ended. Renaming a code later is technically possible, but historical reports either re-label the past or split one line into two, and both outcomes cost an argument at year end.

Put one person in charge of the configuration log: a single dated list of what was added, changed or removed, and by whose approval. Agree a freeze rule before the first table is filled: after sign-off a table is locked, and anything new is added only with a written reason and a date.

The test of a good structure is a question, not a menu: can the new system answer revenue per room type per market segment without a spreadsheet? If it cannot, the structure is not finished.

Room types and room numbers: what has to be decided first?#

Decide the room type list before anything else, because a room type is the unit that rates are priced against and reports are cut by. A room is a physical door with a number; a room type is a sellable category, and the two must be counted separately.

Every physical room belongs to exactly one room type, and the count per type must match the housekeeping list on the day of cutover. A mismatch here becomes a wrong availability figure every night. Keep the type list short enough for the front desk to use under pressure: a type that differs only by floor or view is usually better handled as an attribute than as a separate type.

Attributes such as bed setup, view, balcony and accessibility belong in the room record, not in the type name. Otherwise every attribute combination multiplies your rate codes. Connecting rooms are a relationship between two room numbers, not a type; record the pair so the reservation screen can offer them together.

Agree the room numbering scheme and the floor logic before data entry, including how out-of-order and out-of-service rooms will be marked and for how long. Decide what to do with rooms that are physically real but not sold, such as a manager's flat or a storage room, and record the reason in the configuration log.

Before sign-off, check that total rooms in the system equals total rooms in the building, and that every type has at least one rate code planned against it.

When the room table is signed, the physical facts move across as part of the wider data migration. The logic below is not copied; it is rebuilt.

Rate codes and packages: how many do you need?#

One rate code per combination you actually sell and actually report on. More codes multiply maintenance and the chance of a wrong price; fewer codes lose the ability to tell two products apart in a report.

A rate code carries a room type link, a board type, a cancellation and guarantee policy, a validity period, a market or segment link and any package inclusions. If two of those differ, they are two codes. Board types should be a short fixed list agreed once, because they appear in confirmations, in reports and in the guest's expectation of what is included.

Children and extra beds need a written rule before configuration: the age bands, whether the third bed is charged, and which rate codes allow it. Leaving this to the front desk produces inconsistent bills. A package that includes breakfast, dinner or a spa credit must split into revenue codes when it is posted, so decide the split with the accountant before the package is created.

Derive seasonal and length-of-stay rates from a base rate rather than duplicating the same numbers across codes. Duplication is where a price change gets missed. Use a naming convention that survives staff turnover, for example board type, then flexibility, then room type, so a code can be read without opening it.

Before sign-off, create one booking on every rate code in the test environment, post the charges, and read the resulting bill line by line.

Revenue codes, payment methods and taxes: who decides?#

The accountant decides the revenue code list and the tax settings, the hotel decides how daily operations map onto them, and both sign the same sheet. This is the table where a shortcut costs the most, because it feeds the accounting export every night.

A revenue code is the bucket a charge lands in, such as room, food, beverage, spa or minibar. It is what the day-end export reads, so it must match the accounting chart, not the front desk's habits. Keep the list short and stable: a new code for every small item fragments year-over-year comparison, and a comparison nobody can make is a report nobody reads.

Payment methods are not revenue codes. A payment settles a bill and does not create revenue, so mixing the two makes both the revenue report and the cash report wrong. Tax settings are entered as the accountant instructs; this guide gives no rates and no invoice rules, because those depend on the taxpayer's situation and change. Confirm dates, penalties and your own case with your accountant or legal adviser.

Build the mapping table once: PMS code on the left, accounting account on the right, one line per code, signed and dated, and keep it with the configuration log. Corrections must be possible without deleting: check that the system voids and reverses a posting rather than removing it, so the day's totals still reconcile. What moves at day end, and how to check it arrives intact, is covered in the day-end export guide.

Before sign-off, post one charge of each type and one payment of each method, close the business day, and compare the day-end totals with what the accountant expects to see.

Market and source codes: why set them before go-live?#

Because they are attached to the reservation at the moment it is created. A booking taken without a segment code cannot be given one later, so the data is lost rather than delayed.

Keep two separate fields. The market segment describes who the guest is, such as leisure, corporate or group. The source describes how the booking arrived, such as direct, agency, tour operator or walk-in. Mixing the two into one list destroys both reports: you can no longer see which channel brings which kind of guest, which is the question the list exists to answer.

Keep the list short enough that a reservation agent can choose in a few seconds, and include one "other" code that someone reviews every month rather than letting it grow. Make the choice mandatory in the booking screen, with no default, because a default code silently absorbs every rushed booking and looks like data. Map each connected channel to exactly one source code before the channel goes live, so channel bookings do not arrive as unknown.

Check one week after go-live: count the bookings sitting on the default or "other" code, and treat a high count as a training problem, not a system problem. The design of the segment list itself is covered in the guide to market segment codes for hotels.

Users, roles and document templates: what does the front desk need on day one?#

Named accounts with the smallest role that lets each person do their job, plus the documents a guest actually receives. Both are configuration, not training, and both are usually left to the last week.

One account per person, never a shared reception login. The audit trail is the reason the system records who did what, and a shared login throws it away. Build roles by task rather than by job title, because two people with the same title often need different permissions, and a title-based role is either too wide or too narrow.

Hold the sensitive permissions in few hands: rate changes, voids and reversals, refunds, night audit and the day-end close. List who holds each one and review it after the first month. Prepare the document templates the hotel actually issues, with the legal details and the language variants the guest profile needs, and test each one by producing a real document in the test environment.

Agree the deactivation routine for leavers and for seasonal staff before go-live, so access does not outlive the employment. A fuller treatment of permissions is in the user roles and permissions checklist.

How do you know the configuration is finished?#

When every owning department has signed its own table and one full test week has run end to end, from a booking through the night audit to the accounting export. A signed table without a test week is an intention, not a result.

Keep a sign-off sheet with four columns: table, owning department, date and version. A table without a signature is still open, whatever the project plan says. Run the test week across the whole chain: bookings on several rate codes, charges on every revenue code, one payment of each method, a night audit, and an accounting export compared with the accountant's expectation.

Freeze the configuration during the test week and log every change, because a moving configuration makes the test result meaningless. Decide in advance what may wait until after go-live, such as new packages, extra reports and derived rates, and what may not, such as room types, revenue codes and the segment list.

Hand the signed sheets and the configuration log to whoever runs training, so the trainer teaches the system the hotel actually configured rather than the vendor's demo data. Plan the first review for about a month after go-live: read the reports, count the bookings on default codes, and correct the list rather than working around it.

What to do next#

Write the dependency order on one page and name the owner of each table, then fill the tables in that order and refuse to move on until the previous one is signed. The rooms define what can be sold, the rates define at what price, the money codes define how it reaches the accountant, the segment and source codes define what you will be able to learn later, and the users and documents decide whether the front desk can work on the first morning. Data transfer and the cutover night come after this, not instead of it.