Why every property defines occupancy differently — and how to stop
A group report is a governance document. If the definitions are not owned centrally, the number is a negotiation.
Quick answer
Group reporting disputes are definition disputes. Fix 1 denominator, 1 exclusion rule and 1 time basis before comparing 2 properties; a group dashboard without drill-down to the property ledger is a screenshot, not a control.
Written by Website technical team
Key points
- Most group reporting disputes are definition disputes, not data disputes.
- Occupancy needs one denominator, one exclusion rule and one time basis.
- Central standards should define the metric; properties should own the explanation.
- A group dashboard without drill-down to the property ledger is a screenshot, not a control.
Why do the numbers disagree?
One property excludes out-of-order rooms from available inventory; another includes them. One counts a room as occupied on the night of arrival; another counts it from check-in time. One includes complimentary rooms in ADR; another excludes them.
None of these choices is necessarily wrong. They are policy choices. The problem starts when they are implicit and different across the portfolio.
What does a group need to define for occupancy?
At minimum: the denominator (total rooms, sellable rooms, or rooms available after out-of-order), the exclusion rules, the time basis (night audit date or calendar date), and the treatment of house use, complimentary stays and day-use rooms.
Write the definition down once, publish it, and make the system calculate it that way. If a property needs a local view, it can have a local report — but the group metric should not change meaning by property.
| Metric | Decision to make | Common source of dispute |
|---|---|---|
| Occupancy | Denominator and exclusions | Out-of-order and house-use rooms |
| ADR | Which revenue and which rooms | Complimentary, packages, day use |
| RevPAR | Revenue basis and inventory basis | Package allocation and outlet revenue |
| Segment | Segment hierarchy and ownership | OTA vs. direct vs. corporate |
| Total revenue | Included outlets and services | Spa, golf, transport, service charges |
What should be central and what should stay local?
Central should own the definitions, the chart of accounts mapping and the reporting calendar. Local should own the explanation of variance, the operational context and the corrective action.
A useful rule: central defines the metric, local explains the movement. When properties can redefine the metric, the group meeting becomes a definitions seminar.
How should consolidation work?
Consolidation should read from the same reporting layer as the property reports, not from a separate spreadsheet assembled by each property. If the group number cannot be drilled down to the property ledger, it is not auditable.
Currency, tax and calendar differences need explicit rules. A group with properties in multiple countries should decide whether consolidation happens at constant currency, at month-end rates, or both.
- One reporting layer for property and group
- Drill-down from group metric to property transaction
- Explicit currency and tax rules
- A locked reporting calendar with versioned restatements
What should a group dashboard actually show?
A dashboard should surface exceptions and trends, not just totals. The useful questions are: which property moved, by how much, and why. A wall of green arrows is not a control system.
- Occupancy, ADR and RevPAR versus budget and last year
- Revenue mix by property and segment
- Rate integrity: overrides and below-floor rates
- Open folios, credit exposure and AR ageing by property
- Interface and close exceptions that affect the numbers
How do you roll this out without a two-year project?
Start with the definition sheet and the chart of accounts mapping. Then configure one pilot property and run a parallel close against the existing report. Resolve the differences in writing before the next wave.
The rollout should produce a reusable configuration package and a shorter checklist for each subsequent property. If every property needs a bespoke report, the group has a template problem, not a software problem.
How should group reporting change by property size?
In a 10–60 room property, reporting is usually one page read by the owner or general manager. That does not make definitions optional. The property still has to choose a denominator for occupancy, a time basis for the night and a treatment for out-of-order and house-use rooms. The difference is that the choice can be made by one person and written down in a paragraph. If the property belongs to a group, even a small one, the local habit has to give way to the central definition, and the person who prepares the daily sheet needs to know which figure is the group figure and which is local. Staff time is limited, so the report should be short and generated from the same data as the ledger. A spreadsheet maintained by hand alongside the PMS is the usual source of a number that nobody can later explain. The definition sheet can be a single page, but it should be dated and kept with the report so a later reader can see which rules applied.
Between 60 and 250 rooms, reporting splits by department and by period. There is a daily flash, a monthly close and a segment view that the sales team argues about. The property is large enough to have real allocation questions: packages, outlet revenue and service charges. It is also the band where a group standard is most likely to be tested, because the property has its own routines and a manager who can defend them. The system should calculate the group metric, not a local spreadsheet, and the property should keep the ability to explain a variance with operational context. A chart of accounts mapping from local accounts to the group hierarchy needs an owner on both sides. The 30-day close calendar should be fixed and published, with restatements versioned rather than overwritten. The daily flash should carry the same definitions as the monthly close, or the month starts with a reconciliation exercise. That is a governance choice, not a reporting preference, and it should be agreed before the first close.
Above 250 rooms, and in resorts, reporting covers multiple revenue centres and a larger share of non-room income. Spa, golf, banqueting, transport and retail all need an inclusion rule, and package allocation determines whether ADR and RevPAR mean anything. Daily operational reporting and monthly financial reporting serve different audiences, and the property needs both without maintaining two sets of numbers. Internal audit will look for a trail from the group figure to the transaction, so drill-down is a control rather than a convenience. If the property is part of a group, the centre needs a close status and an exception view each morning, while the property needs the detail behind its own exceptions. Currency and tax rules should be explicit at this level, because a resort may sell in one currency, report in another and account in a third. The centre should also know which property owns a disputed number, because consolidation without an owner becomes a monthly argument. A named owner on each side usually shortens that argument at close.
Decide the definitions first and the dashboard second. The order that works is: occupancy denominator and time basis, ADR revenue basis, segment hierarchy, total revenue inclusions, chart of accounts mapping and the reporting calendar. Then decide which metrics the centre sees daily and which are reviewed at close, and who is allowed to restate a prior period. A new property joining mid-year needs a like-for-like rule agreed before its first report, not after the first comparison. The boundary conditions are local statutory accounts, local tax and the property’s own operational reporting; the group layer should map to these, not replace them. One reporting layer, one definition sheet and a drill-down to the property ledger are the minimum. Without them, the group meeting spends its time negotiating what the number means instead of what to do about it. The definition sheet should be versioned, and every report should name the version it used and the date it changed. That single habit prevents most of the arguments about which number is correct.
- Which occupancy denominator and time basis will the group enforce?
- Who owns the chart of accounts mapping on each side?
- Which metrics are daily, and which are reviewed only at close?
- How is a new property shown in like-for-like comparisons?
- Can every group figure be drilled down to a property transaction?
| Property band | Typical pattern | Decide first |
|---|---|---|
| 10–60 rooms | One daily sheet; definitions written once by the owner | The occupancy denominator and time basis |
| 60–250 rooms | Department reporting and a monthly close; segment views | Which system calculates the group metric |
| 250+ rooms or resort | Several revenue centres; package and outlet allocation rules | How total revenue and segments are defined |
| Group / multi-property | Central definitions and one reporting calendar | Restatement and like-for-like rules |
Frequently asked questions
Should every property use the same chart of accounts?
The group reporting layer needs a common mapping, but properties can keep local statutory accounts. The important thing is a documented mapping from local accounts to the group hierarchy.
How do we handle a property that joins mid-year?
Define the restatement rule in advance: whether prior periods are restated, and how the new property is shown in like-for-like comparisons. Ambiguity here destroys trust in the group report.
Can properties keep their own reports?
Yes. Local reports can exist for local decisions. The constraint is that the group metric must be calculated from the central definition, not re-keyed locally.
How often should the group report be reconciled?
Daily for operational metrics, and at every close for financial metrics. The reconciliation should be automatic and exception-based, not a monthly spreadsheet exercise.
What is the first thing to fix?
The definition of occupancy and ADR. They are the most argued-about numbers and the easiest to define once. Publish the definition and make the system enforce it.
Updated 2 November 2026
Knowledge
