What a Hotel Management Company Loses to Inconsistent PMS Usage Across Properties

The report that takes three phone calls

An owner asks how the two properties in the same market compare on group business. A simple question. Your regional director pulls the reports, notices the numbers do not line up, and calls both general managers. One GM explains that their "Group" segment includes anything booked off a rooming list, including a family reunion of six rooms. The other GM books the same reunion as transient with a discount rate code somebody set up in 2019. Both are following the process. The process was never written down, so each property wrote its own.

Two days later the owner gets an answer with a footnote. That footnote is the cost of inconsistent PMS usage, and it recurs every month, on every portfolio question, until somebody fixes the thing under it.

The diagnosis vendors sell is the wrong one

Search the problem and every result on page one reads it the same way: your properties are on different systems, and the fix is one system. Multi-property PMS marketing from Hotelogix, WebRezPro, Mews, Stayntouch and the rest is written entirely at the system layer. Centralised dashboards, single sign-on, portfolio occupancy and RevPAR in one view. Hotelogix lists "consolidated reporting requires spreadsheets" as the warning sign that you need its multi-property product.

The symptom is described precisely. Corporate requests manual exports from each GM to compare occupancy and RevPAR, then reconciles them by hand. What the vendor posts never mention is why the exports need reconciling. They do not say the words rate code, market segment, or comp room. They assume the data would line up if only it lived in one place.

For most management companies we have looked at, it already lives in one place. The same PMS runs at every property, sometimes the same version, sometimes with the same corporate login. The dashboards the vendor promised are already there. They are just not believable, because the categories feeding them were defined by whoever set up each property, on the day they set it up, with no reference to the property next door.

Consolidating software you already share does not fix that. It gives you the same six definitions of "Group" on one screen instead of six.

What inconsistent usage actually looks like

The pattern has a small number of recurring shapes. We see the same ones at a twelve-property regional operator and a sixty-property third-party manager.

Rate codes named by whoever built them. One property has 40 active rate codes. Another has 210, of which maybe 30 have been used this year. Codes for the same negotiated corporate account differ across properties, so a portfolio-level view of that account's production requires someone to map codes by hand. The map lives in a spreadsheet owned by one analyst, and it is out of date the week after a property adds a promotion.

Market segments applied by feel. The PMS ships with a segment list. Each property has amended it. Government, crew, wholesale, and negotiated business get sorted into whichever bucket the front desk agent was trained to use, and training turns over faster than the segment list gets reviewed. STR's own benchmarking guidelines define group as ten or more rooms per night sold under a contract, and contract as a consistent block over 30 days. Ask three of your GMs to state those thresholds from memory and see how many answers you get.

Comp and house use booked three ways. One property posts complimentary rooms at a zero rate under a comp rate code, one posts them at rack and adjusts revenue off, one books house use as an out-of-order room so it never appears in occupancy at all. STR excludes complimentary rooms from rooms sold, full stop, and treats rooms given free under a promotion the same way. Any property doing this differently is reporting a different occupancy number than the one its comp set is reporting, and your portfolio RevPAR is quietly blended from both.

Channel and source fields left to default. Distribution cost analysis depends on booking source being captured consistently. At many properties the field is populated correctly for OTA bookings because the interface does it, and populated by whatever the agent clicked for everything else.

None of these is a software defect. Every one of them is a decision that was made locally because it was never made centrally.

The industry already wrote the standard

Here is what makes the vendor diagnosis so frustrating. Hospitality is one of the few industries that solved this problem decades ago, on paper, and the solution is not a PMS feature.

The Uniform System of Accounts for the Lodging Industry, USALI, exists precisely so revenue and departmental results are categorised identically across properties, owners, and operators. It is what makes a portfolio number disaggregate back to property and line item without a footnote. The 12th Revised Edition became effective on 1 January 2026, and among its changes it expanded the definitions for each rate category used to segment rooms revenue and refined how distribution channels are reported. The standard for what "Group" means, what a comp room is, and how a negotiated rate should be classified is not something your company has to invent. It has to adopt it.

Most management companies will tell you they are USALI compliant. What they mean is that the accounting system's chart of accounts follows USALI. The PMS configuration that feeds the accounting system usually does not, because nobody owns the translation between the two. The controller inherits whatever the front office sends. The front office was never told the front office was part of the financial reporting chain.

The gap between "our P&L follows USALI" and "our PMS segments follow USALI" is where the three phone calls come from.

What it costs, in the order it costs it

The direct cost is the analyst time spent reconciling exports, and it is real but small. Count the hours your finance and revenue teams spend mapping codes and re-cutting exports each close, and you will have the number the automation vendor quotes back to you as the payback. It is rarely the biggest line.

The larger costs are quieter.

Benchmarking that lies to you. If your comp room treatment differs from STR's, your STR index is off by whatever the difference is, and it is off in one direction at some properties and the other direction at others. Revenue management decisions are being made against a comp set comparison that is partially fiction.

Owner reporting that does not survive scrutiny. Third-party managers live on owner trust. An asset manager who finds two of your properties reporting the same account under different segments will ask what else is inconsistent. That question is expensive to answer and worse to be unable to answer.

Revenue management systems fed inconsistent inputs. An RMS forecasts by segment. If segment assignment varies by property, the model at each property is learning a different thing from the same kind of booking. You will read the result as the model underperforming at some properties, and you will be pitched a recalibration or an upgrade. The model is fine. The inputs are not the same.

Every future automation project inherits the problem. This is the one that matters most for anyone considering a technology investment. A centralised reporting layer, a data warehouse, an AI forecasting tool, a commission reconciliation product: each of them consumes segment, rate code, and source fields as if they mean one thing. If they mean six things, the project spends its first three months discovering that, and its budget on cleanup that was never scoped. We have written about this pattern when the front end modernises and the back office has three versions of the truth. Hotels have it too, with better acronyms.

Why the fix is unglamorous, and why that is the point

The fix is a standards document, an owner for it, and a governance rhythm that outlasts GM turnover. Segment definitions aligned to USALI and STR. A controlled rate code taxonomy with a naming convention and a retirement process. One documented treatment for comp and house use that matches how your benchmarking provider counts rooms. A field-level spec for what the PMS must capture at booking, and a periodic audit that checks it did.

None of that is a product. Nobody will demo it at a trade show. It also costs a small fraction of a PMS migration, carries none of the migration's operational risk, and is the prerequisite for any migration or reporting tool to deliver what its brochure says.

Which is why we tell management companies who ask us about consolidating their PMS to hold the question. If your properties are on the same system, you are not a consolidation candidate. You are a standardisation candidate, and the difference is about a year and a large amount of money. If your properties are on different systems, standardise the definitions first anyway, because a migration is the one moment when every property's configuration gets rebuilt, and rebuilding it to no standard just moves the inconsistency to a new vendor.

We hold a similar line on most operations problems pitched as software problems. It is the same logic as knowing when AI is the wrong answer: the tool cannot fix a definition nobody made.

The questions that decide it

Before you take another vendor call, answer these internally.

• Can you state, in writing, what qualifies a booking as Group at every property, and does every property's PMS enforce it?
• How many active rate codes does each property have, and who approved the last ten?
• How does each property post a comp room, and does that match what your benchmarking provider expects?
• Who owns the mapping between PMS segments and USALI rooms revenue categories, and when was it last reviewed?
• If two properties disagree on a number, who decides which one is right?

If the honest answer to more than one of these is "it depends on the GM," the migration you are being sold will not resolve it. The definitions will. Deciding which definitions, sequencing the cleanup so it does not disrupt properties mid-season, and building the governance so it holds after the next round of GM changes is where the work actually lives.

That is the part we do. If corporate is still calling general managers to reconcile a portfolio report, talk to us about standardising before you migrate.