One report across several hotels: what a group needs to compare and what must stay separate

Multi-property hotel reporting group work compares hotels on numbers that mean the same thing in each one. A group first agrees definitions (sellable rooms, occupancy, revenue, board), one calendar and one currency, then builds the reports. Guest records, staff data and access rights stay inside each hotel.

Two hotels send their monthly pack. One counts 120 rooms, the other 112, because the second removes the rooms under renovation. The occupancy figures arrive, the meeting starts, and the first twenty minutes go to a definition nobody wrote down. After reading this you will know which definitions to agree first, which reports a group actually needs, and what each hotel keeps apart.

Why do two hotels' numbers not compare?#

Because the same word means different things in each hotel: a room that cannot be sold, a breakfast inside the rate, a payment taken at booking. A report is only as good as the definitions underneath it.

The occupancy denominator differs. One hotel divides by all rooms, another by rooms it can actually sell after removing out-of-order, out-of-service and house-use rooms. Revenue differs too: room revenue only, or room revenue plus food and beverage, spa and other outlets; gross of channel commission, or net; recognized at booking, or at the stay.

Board codes travel badly. BB, HB, AI and RO are the same four letters in every hotel and different products in each, so a half-board comparison compares packages rather than value. Room type names compare labels, not rooms: a standard room is a size and a view in one property and something else in the next. Cancellations, no-shows and complimentary stays are handled by habit, not by rule, and each habit moves the numbers.

The usual outcome is a first group report that ranks hotels, a meeting that does not trust the ranking, and an argument about definitions instead of about performance.

Which definitions must a group agree before it reports?#

Four, at minimum: what a sellable room is, what occupancy divides by, what counts as revenue, and what each board code includes. Write them on one page and make every hotel produce its numbers that way.

Sellable rooms are total rooms minus out-of-order and out-of-service, with a written rule for house use and complimentary rooms, and a decision on whether the figure is fixed for the month or measured daily. Rooms sold need their own line of cases: a no-show is not a room sold, a day-use room is, and a room moved to another hotel for an overbooking is neither. State each case.

Occupancy is rooms sold divided by sellable rooms. Türkiye's published figure uses a different base: the occupancy rate in Ministry-certified (İşletme and Basit) facilities was 49.54% in 2025 (Source: Ministry of Culture and Tourism, accommodation statistics 2025). Never set an internal hotel figure beside it without saying the bases differ.

Revenue should appear as two separate lines, room revenue and total revenue, with a rule for commission, for city or accommodation tax, and for attributing outlet sales to the stay or to the outlet's own day. Fix the ADR and RevPAR formulas in writing, and compute RevPAR always from the same denominator as occupancy, otherwise the two numbers disagree by design. Define board codes by content (what is included, service hours, where it is served), not by the letters, and keep the definition next to the rate plan in every hotel. The formulas behind these figures are covered in more detail in RevPAR, ADR and occupancy rate: formulas and common mistakes.

For example, take two hotels of 100 rooms each, 70 rooms sold. The hotel that removes 8 rooms under renovation reports 76.1% occupancy; the hotel that counts all 100 reports 70.0%. Same performance, different arithmetic.

Which calendar and which currency?#

One business-day close, one fiscal calendar and one reporting currency, each with a written rule for the boundary cases.

The night audit closes the day. If hotels close at different hours, a late check-in lands in different days in different properties, so fix one close time and one rule for arrivals after it. The group's consolidation calendar must match the hotels' accounting periods, or every month-end needs a manual adjustment. Stays that cross the month end need one rule: either each night falls in its own month, or the whole stay falls in the arrival month. Pick one and apply it in every hotel.

For the reporting currency, name the source and the date. Use daily central-bank exchange rates, take the rate of the business day, and apply it once. Keep the hotel's own ledger in its own currency and convert only in the reporting layer, so the legal records and the group view never contradict each other. Set budgets and forecasts in the reporting currency with the rate assumption written beside them, so a currency move shows up as a currency move and not as a management failure.

Which reports does a group need, and which does it not?#

A short list: a daily flash, a weekly pace against the same week last year, a monthly consolidated view by hotel and segment, and an exceptions list. Everything else is a question, not a report.

The daily flash carries rooms sold, rooms available, revenue, ADR, RevPAR, arrivals, and the three largest movers against the same day last year. One page, same shape every day. The weekly pace compares rooms on the books for a future date with the same date last year, measured at the same point in time, so pickup is visible before the month arrives. The monthly consolidated view is hotel by month by segment, built on the agreed definitions, with a total that shows the mix and not only the sum.

The exceptions list is what the group actually reads: ADR below a floor, occupancy below budget by more than a set margin, receivables aging past a set number of days, a hotel that closed its month late. A group does not need a RevPAR ranking without size and segment context, a blended group occupancy that hides a weak hotel, a per-hotel dashboard nobody opens, or any report a person has to rebuild by hand each month. When the numbers raise a question rather than answer one, asking plain-language questions of your own hotel data is often faster than a new scheduled report.

The test for a new report: which decision does it change, who makes that decision, and how often. If there is no answer, it is a question to ask, not a report to schedule.

What must stay separate inside a group?#

Guest records, staff data and access rights stay with the hotel that holds them. The group sees aggregates, and individual guest records only through a named role with a lawful basis.

Each hotel holds its own guest records, and consent given to one hotel is not consent for the group's marketing. Group reporting needs counts, segments and nationality aggregates, not names. Consent, retention and export are set per hotel under KVKK (kişisel verilerin korunması kanunu). How long a record is kept and who may see it are questions for your own legal adviser, because the answer depends on the hotel's registration and its own file.

Staff data follows the same line: schedules, performance and payroll belong to the employing hotel; group HR sees headcount and cost, not the individual file. Access is named and bounded: a group finance user reads all hotels, a hotel manager reads one, a regional director reads three. Nobody shares a login.

On the product side, stated plainly: our groups and portals line is built, not live. It runs single hotels and groups from one login, and travel agents and corporate clients book through their own portals. Each hotel's data is separated at the database level, also built. You can read more about hotel groups and partner portals in one login.

The trade-off is real. Too much separation and the group cannot see a problem in time; too little and one hotel's guest list becomes the group's marketing list.

Who owns which number?#

Group finance owns the dictionary and the consolidation; each hotel owns its source data and its close; the owner reads the exceptions and approves changes to the dictionary.

Group finance keeps the one-page dictionary, approves every change to it, runs the consolidation and signs off the reporting-currency rule. The hotel manager and hotel finance produce the numbers the dictionary defines, close the day and the month on time, and raise anything the dictionary does not cover instead of inventing a local rule. The owner and board read the exceptions and the consolidated view, and approve a dictionary change rather than a one-off spreadsheet fix that only one person understands. IT keeps the mapping between the property system's fields and the dictionary, and retests it after every change to either side.

The common failure is quiet: a definition changes in a meeting, never reaches the system, and two reports disagree for a quarter before anyone traces it. The change rule prevents it: a dictionary change is dated and versioned; reports issued before the change keep the old definition and say so on the page.

What goes on the one-page data dictionary?#

One page, one row per term, with the definition, the formula, the source field and the owner. Ten rows are enough to start.

Each row carries the term, a plain definition, the formula, the source (which system and which field), the owner and the date it last changed. Room type names belong on the page too, as one name shared by the property system, the channels and the door sign, so a comparison by room type compares rooms; see naming room types for how to set that up. Add the business-day close time and the month-end rule as two written lines at the bottom, because they decide which month a number lands in.

Keep the page where every hotel can read it, and print the version number on every report that uses it. Then test it: give the page to a new hotel's finance manager and ask them to produce the monthly pack from it without asking a question. If they cannot, the page is not finished.

What to do next#

Write the ten-row dictionary this week, before any new report. Give it to each hotel, ask for one number produced from it, and compare the working rather than the result: the definitions, the calendar and the currency are the report, and everything the group builds afterwards sits on top of them. If you want to see how a single system handles groups and per-hotel separation, request a briefing.