RevPAR Has Three Definitions
in Every Hotel Group
(And None of Them Are Wrong)

Three numbers.
Same property. Same month.

Every hotel group at the ten-to-a-hundred property scale produces at least three RevPAR figures every month, and all three of them disagree.

The operations team has one. The commercial team has another. The revenue management system produces a third, and the channel manager often produces a fourth. By the time anyone has spent a year inside the group, they have learned that asking "what is our RevPAR" is a question with several defensible answers depending on who you ask. Reports get circulated and quietly reconciled in side conversations. Budget meetings hover on whose number to use. New hires assume there is an authoritative version somewhere and eventually discover there is not.

This is not a quirk of unsophisticated revenue management. It happens at every hotel group I have worked with, at every revenue conversation I have been inside, and -- as the rest of this piece will show -- at the most standardised hotel company in the world.

The conventional response is to say the group needs to agree on a definition. This is the response every group has already tried, and the one that has never worked. The reason is not that revenue managers are undisciplined. It is that the problem is architectural, not behavioural, and no amount of governance documentation will fix what only structure can.

Each definition
is defensible

Before getting to why this is a structural problem, it is worth taking the three definitions seriously, because each of them has internal logic.

The operations team's RevPAR is grounded in physical reality. Available rooms means rooms that exist. Occupied rooms means rooms with bodies in them -- including complimentary stays, including house use, because those rooms are physically unavailable to be sold and the front desk is treating them as occupancy regardless of who is paying. Revenue is what flows to the P&L. This is the lens that matches what the property actually experiences. It is the right lens for understanding utilisation, maintenance scheduling, and the operational reality of the building.

The commercial team's RevPAR is grounded in saleable revenue. Available rooms excludes out-of-order inventory during renovations and excludes blocks held for groups that are committed but not yet picked up. Occupied rooms typically excludes house use but includes complimentary stays, because those stays reflect customer relationships that have commercial value even when uncompensated. Revenue is net of rebates because the commercial team is measured on what the group actually earned. This is the lens that matches the business of selling hotel rooms.

The revenue management system's RevPAR is grounded in demand signal. Available rooms is whatever the booking engine sees as bookable inventory. Occupied rooms typically excludes both comps and house use, because neither reflects market demand and including them distorts the rate optimisation algorithm. Revenue is gross of rebates because rebate processing happens downstream of the booking and is not part of the rate the customer agreed to pay. This is the lens that matches the work of optimising prices against forecasted demand.

For the same property, the same month, the same physical events, each lens produces a different RevPAR. Take a 200-room property over a 31-day period with 4,800 rooms physically occupied (including 150 complimentary stays and 50 house-use rooms), gross room revenue of 920,000 euros, rebates of 48,000 euros, and 200 out-of-order rooms over the period:

Three numbers. Same property. Same month. None of them is wrong. They are answering slightly different questions, and each question has its own defensible answer.

Why agreement
never holds

The conventional advice when this happens is to bring the three teams into a room and agree on the definition. This has been tried, in every group that has ever encountered the problem, and it has never produced lasting agreement.

It is not that the teams are unwilling to agree. It is that even when they do agree, the architecture does not enforce the agreement, and the agreement decays the moment someone reaches for a number under deadline pressure. The dashboard implements its own version. The export script implements its own version. The revenue management vendor's report implements its own version. The agreement exists in a meeting room; the calculations exist in software that does not know about the meeting.

There is a second, less obvious failure mode. Even when the agreement does hold, and the definition does change deliberately, the architecture does not handle the methodology transition. The historical numbers were computed under the old definition and remain in dashboards comparing them against the new. The change is clean going forward and silently incoherent looking backward.

This is not hypothetical. In my past life as a revenue person at Marriott -- by any reasonable measure the most standardised hotel company in the world -- rebates historically had their own line on the room revenue statement. Each segment line (leisure, OTA, wholesale, and so on) was gross of rebates. Below all the segment lines was a rebate line, expressed as negative revenue. The room ADR at the bottom of the statement was net. The segment ADRs were gross. When budgeting, I would forecast the next year's rebates as a percentage of total revenue and work from there.

One year, the accounting methodology changed. Rebates would now be applied at the rate level on every close of day, distributed across segments at source rather than aggregated below the line. This was a clean, deliberate, organisation-wide change made for good accounting reasons. The effect, however, was immediate: the ADR of every segment dropped, because the rebates that had previously been pulled out below the line were now reducing each segment's revenue at source.

My regional vice president, in the budgeting cycle that followed, insisted that all segment ADRs needed an x percent increase for the following year. She was not being unreasonable; she was using the budgeting discipline she had always used. What she did not know -- because nobody had told her in those terms, and there was no architectural mechanism that would have surfaced it -- was that the segment ADRs she was looking at had been computed under a different methodology than the historical comparison she was anchoring on. The numbers had the same name. They meant different things. The year-over-year comparison was not apples-to-apples, and she was asking for performance improvement against a denominator that had quietly shifted underneath her.

This happened at Marriott. With global standards. With internal audit. With operations manuals that documented the change. The documentation existed; the regional VP either had not seen it or had not registered what it implied for her year-over-year analysis. And this is the part that matters: documentation cannot do what only architecture can do. If the semantic layer had held the metric definition as a versioned object, the year-over-year comparison would either have refused to run or returned with an explicit annotation that the methodology had changed during the comparison period. Documentation is a request to the human. Architecture is an enforcement on the software.

If this happens at Marriott -- with the resources, the discipline, and the standardisation that company has -- it happens at every group below it, with worse documentation, less standardisation, and faster turnover among the people who would know.

The architectural answer

The fix is not better definitions. It is not better governance. It is not better training. The fix is architectural, and it is specific.

A semantic layer holds metric definitions as first-class objects in the system. Each metric -- RevPAR, ADR, net ADR after distribution, occupancy, channel contribution, displacement, pace, length of stay -- has exactly one implementation. That implementation is computed by the platform. Every consumer that needs the metric reads the canonical value rather than implementing its own version. The dashboard does not implement RevPAR; it asks the semantic layer for RevPAR. The export does not implement RevPAR; it asks the semantic layer for RevPAR. The revenue management vendor's report does not implement RevPAR; it reconciles its own internal calculation against the canonical one and surfaces the difference if there is one.

This sounds like a small architectural detail. It is not. It is the structural commitment that determines whether the organisation can answer the question "what is our RevPAR" with a single number or with several.

The semantic layer also holds methodology changes as versioned events. When the definition of net ADR after distribution changes because the group's contract with an OTA shifts from commissionable to merchant model, the layer records the change with a date. Year-over-year comparisons across the boundary either refuse to run or return with the change explicitly flagged. The regional VP at Marriott would not have been able to ask for an x percent increase on a metric whose underlying methodology had changed without the system surfacing the change. Not because the system was being clever; because the system held the metric's history as data rather than as institutional memory.

This is what makes the semantic layer load-bearing rather than ornamental. Without it, every team computes its own version, every methodology change degrades historical comparability silently, and the organisation has no architectural way to know that the number it is acting on is not the number it thinks it is. With it, the question "what is our RevPAR" has one answer, the question "has the methodology changed in the comparison period" is surfaceable, and the budgeting conversation actually rests on common ground.

The Uniform System of Accounts for the Lodging Industry -- the USALI, currently in its twelfth revised edition -- provides canonical definitions for most of the metrics that matter. The semantic layer should align to USALI where USALI has spoken, and document its deviations where it deviates. The standard exists. The work that has not been done at the 10-to-100 property scale is encoding the standard architecturally and making it enforceable across every system that asks the platform for a number.

The pattern
generalises

RevPAR is the most visible case because it is the most-cited metric in the industry. The same pattern applies to every metric that matters.

ADR has multiple definitions depending on whether rebates are netted, whether complimentary stays are excluded, and whether out-of-order inventory is subtracted from the denominator. Net ADR after distribution depends on which channel costs are included and how commission models are handled across booking sources. Channel contribution depends on how distribution costs are allocated and how multi-channel attribution is handled when a guest browses on one channel and books on another. Pace depends on the comparison period chosen and the handling of cancellations. Displacement depends on the demand baseline used. Length of stay depends on whether extended stays, day-use bookings, and split stays are counted. Total revenue per available room depends on which ancillary revenues are captured and from which systems.

Every one of these has the same structural risk: multiple consumers, each implementing its own version, each disagreeing with the others, each correct from inside its own lens, and no architectural mechanism that enforces a canonical answer.

The conventional approach is to write more governance documentation. The architectural approach is to encode the canonical definition once and require every consumer to read from it. The discipline is not behavioural; the architecture either enforces it or does not. There is no in-between.

This is the work the application layer cannot do. A BI tool can visualise data; it cannot enforce that the data is computed canonically. A revenue management system can optimise rates; it cannot align its internal definitions to the group's canonical ones. A CRM can segment guests; it cannot guarantee that the segments are defined identically to the segments the commercial team uses. The semantic layer sits below all of these, and its job is to hold the canonical definitions so that everything reading from it gets the same answer.

This is what the substrate is for.

RevPAR has one definition. The architecture decides whether the organisation has one too.