Source: https://oguzerol.com/en/hotel-reservation-records-reporting-screens/

[![Turn booking records into a daily view. Illustrative interface: Today's arrivals | Today's departures | Room status | Channels. Bring records together; See the daily picture; Compare channels.](https://oguzerol.com/gorseller/hizmet-kapaklari/otel-rezervasyon-kayitlari-rapor-ekranlari-seri-v2-en.webp)

View full size](https://oguzerol.com/gorseller/hizmet-kapaklari/otel-rezervasyon-kayitlari-rapor-ekranlari-seri-v2-en.webp)

# Hotel Reporting Screens: Occupancy, ADR, RevPAR and Net Channel Revenue

[Oğuz Erol](https://oguzerol.com/en/about-me/)  |  20 min read

A hotel reporting screen built on your reservation records replaces the morning routine of exporting bookings from the PMS (property management system) or channel manager into a spreadsheet. From the same records it calculates occupancy, ADR, RevPAR, each channel’s revenue after commission, cancellation and no-show rates, and what is already on the books for the coming weeks. I build this screen for your hotel; the front desk sees its view without revenue, while the general manager and owner see the full revenue picture. A gross-only report hides which channel earns after commission, and a file without booking creation and cancellation dates can’t compare the coming weeks with last year.

Below I read one month of a fictional 60-room hotel through this screen: OTA A leads on gross ADR, but after commission the direct channel earns 236 more per night, and week 3 of next month sits 16 points below last year’s position.

## Which numbers does the screen show, and how are they calculated?

Every number on the screen comes from three inputs: available room nights, room nights sold and room revenue. Count those three correctly and the rest is division. The three you know: occupancy = room nights sold ÷ room nights available; ADR (average daily rate) = room revenue ÷ room nights sold; RevPAR (revenue per available room) = room revenue ÷ room nights available, i.e. ADR × occupancy. The two I add:

| metric | formula | what it tells you |
| --- | --- | --- |
| Net ADR | (room revenue − channel commission and distribution cost) ÷ room nights sold | the nightly rate you keep after commission |
| GOPPAR | gross operating profit ÷ room nights available | profit per room once costs are deducted |

Net ADR isn’t defined the same way by everyone; this definition is mine, and the screen prints each formula next to its metric. GOPPAR needs monthly cost data from accounting, so it sits in the owner’s and general manager’s month-end view, not on the daily screen.

Three definitions get written down once, at the start:

- **What counts as room revenue?** I recommend the amount excluding VAT and any local occupancy or tourist tax. Leave taxes in and your ADR is inflated.
- **Which date?** Occupancy and ADR count by stay night: a 4-night booking arriving on the 29th puts 2 nights in each month. “What did we sell this week” uses booking date. Every filter says which date it uses.
- **Which channel does each source map to?** A channel manager can send “Booking”, “booking.com” and “BDC” as three names. A mapping table ties them to one channel; an unmapped new name isn’t dropped into “other”, it goes to sales.

## A sample month: the channel table of a 60-room hotel

*Sample data, fictional. Amounts are in your reporting currency, excluding taxes; the currency is arbitrary, so read the ratios, not the amounts. Commission rates are assumptions; your screen uses the rates in your contracts.* Picture a 60-room independent city hotel. The sample month has 30 days, so 60 × 30 = 1,800 room nights available, of which 1,300 sold.

| channel | room nights sold | gross ADR | room revenue | commission / distribution cost (assumed) | net revenue | net ADR |
| --- | --- | --- | --- | --- | --- | --- |
| OTA A | 620 | 3,400 | 2,108,000 | 18% → 379,440 | 1,728,560 | 2,788 |
| OTA B | 180 | 3,300 | 594,000 | 20% → 118,800 | 475,200 | 2,640 |
| Direct (website + phone) | 260 | 3,150 | 819,000 | 4% → 32,760 | 786,240 | 3,024 |
| Tour operator (net-rate contract) | 240 | 2,500 | 600,000 | none | 600,000 | 2,500 |
| **Total** | **1,300** | **3,170** | **4,121,000** | **531,000** | **3,590,000** | **2,762** |

An OTA is an online travel agency such as Booking.com or Expedia. Direct sales aren’t free either. I assumed 4% for the booking engine fee and card processing only. Add your Google Ads, metasearch or email spend for direct bookings, divided by direct room nights. The break-even: direct keeps its lead over OTA A while its total cost (engine, card, advertising) stays below about 11.5% of the gross rate (3,150 × 0.885 ≈ 2,788), i.e. at most about 236 in marketing spend per direct night on top of engine and card fees. Above that, OTA A earns more net. Do you know your own direct cost of sale? The screen recalculates this monthly from actual ad spend.

The month’s metrics:

- **Occupancy:** 1,300 ÷ 1,800 = 72.2%
- **ADR:** 4,121,000 ÷ 1,300 = 3,170
- **RevPAR:** 4,121,000 ÷ 1,800 = 2,289
- **Net ADR:** 3,590,000 ÷ 1,300 = 2,762
- **Commission and distribution cost as a share of gross room revenue:** 531,000 ÷ 4,121,000 = 12.9%, and 71.5% of that cost comes from one channel, OTA A.

What the table really says: OTA A has the highest gross ADR (3,400), but after commission the order changes. The tour operator gives the lowest net rate and, as the next section shows, also cancels least.

That gap becomes a decision. Every night moved from OTA A to direct is worth 236 more net (3,024 − 2,788); move 100 nights and that’s 23,600 a month. The same 236 is also a ceiling: if winning a night direct costs more than 236 on average beyond engine and card fees, the move earns nothing. OTA A is also the shop window that gets you found. The screen shows the break-even; it doesn’t tell you to drop OTA A.

### How do cancellation and no-show rates differ by channel?

Cancellation rate here is the share of room nights booked for this month’s stays that were cancelled; a no-show is an uncancelled night where the guest never arrived. A booking-count basis is also used; whichever you choose is written on the screen and doesn’t change.

| channel | room nights booked | cancelled | cancellation rate | no-show | no-show rate | stayed |
| --- | --- | --- | --- | --- | --- | --- |
| OTA A | 860 | 222 | 25.8% | 18 | 2.1% | 620 |
| OTA B | 215 | 30 | 14.0% | 5 | 2.3% | 180 |
| Direct | 280 | 17 | 6.1% | 3 | 1.1% | 260 |
| Tour operator | 255 | 15 | 5.9% | 0 | 0% | 240 |
| **Total** | **1,610** | **284** | **17.6%** | **26** | **1.6%** | **1,300** |

*Sample data.* If you charge a no-show fee, it sits on a separate line. I don’t mix it into room revenue: the room wasn’t occupied that night, and mixing it in inflates ADR.

### What’s on the books for next month, and what was there at this point last year?

On-the-books (OTB) means bookings taken and not cancelled for future nights, as of today. On its own it says little; it becomes useful beside OTB on the same day last year (STLY, same time last year). For the sample hotel’s first four weeks of next month (each week 60 × 7 = 420 room nights):

| week | on the books today | occupancy | on the books same day last year | gap |
| --- | --- | --- | --- | --- |
| Week 1 | 286 | 68% | 61% | +7 pts |
| Week 2 | 227 | 54% | 58% | −4 pts |
| Week 3 | 130 | 31% | 47% | −16 pts |
| Week 4 | 92 | 22% | 35% | −13 pts |

*Sample data.* Of week 3’s 130 room nights, 72 are from OTA A, 14 from OTA B, 20 direct and 24 from the tour operator. Apply the cancellation and no-show rates above to that mix and about 105 of the 130 nights materialise: the 31% could fall as low as 25%. That’s a lower bound: the rates cover all bookings in the month, while those still on the books have survived part of their cancellation window, so the real figure lies between 25% and 31%. Last year’s OTB was open to cancellation too, so the raw comparison is like for like and the table keeps showing 16 points. Applying the adjustment to both sides would shrink the point gap (to about 13 in this example) but not the ratio; the adjustment only answers “how many nights will actually fill”.

### Which decision does the table lead to?

In this example the table points one way: no discount in week 1, and for weeks 3 and 4 the first move is not cutting OTA A’s price but the tour operator allotment and the direct channel. Scale first: weeks 3 and 4 have 290 + 328 = 618 empty room nights. Catching up with last year’s position takes 67 room nights in week 3 and 55 in week 4, 122 in total. The order I’d suggest:

1. **Week 1:** 7 points ahead of last year. No discounts; OTA A’s weekend rate can go up a step.
2. **Weeks 3 and 4, tour operator first:** Ask for 40 extra room nights of allotment, released 14 days before arrival. Lowest net rate, but only 5.9% cancellations, and unsold allotment returns to you 14 days out. Forty nights is a third of the 122 needed; the rest has to come direct and, as dates approach, from the OTAs.
3. **A direct-channel offer:** the highest net yield per night. Open a rate for these weeks on your website and to past guests.
4. **If OTA A needs a discount, cap it at about 10% and make it non-refundable:** at 18% commission, a gross rate below about 3,049 drops OTA A’s net under the tour operator’s net 2,500 (2,500 ÷ 0.82 ≈ 3,049; about 10.3% off 3,400). This channel cancels 25.8%, and a refundable discount adds bookings that never turn up.
5. **Look again in 7 days:** the screen shows OTB change between two dates (pickup), next to what was picked up in the same seven days last year. My suggested weekly target: last year’s pickup for the same week + 67 ÷ weeks left. If week 3 is 4 weeks out, that’s about 17 nights a week above last year’s pace (67 ÷ 4 ≈ 16.8). Fall short and the gap isn’t closing, so discuss the next step. Last year’s pickup can only be rebuilt if cancellation dates were kept; otherwise the comparison stays partial until the nightly snapshots build up.

Allotment size and release period are my example assumptions; yours come from your contracts and history. The decision is yours; the screen makes it visible and writes nothing back to the source.

## Where does the data come from, and which PMS fields are needed?

The data comes from your PMS’s reservation export or connection and your channel manager’s report; in many hotels a tour operator spreadsheet is a third source. Some systems offer scheduled file exports, some a connection (API), some only a manual report, which is enough to start with.

The minimum fields the screen needs:

| field | used for |
| --- | --- |
| Reservation number (source ID) | a booking arriving twice updates the existing record instead of counting as new |
| Creation date and cancellation date | rebuilding OTB as of any past day, last-year comparison |
| Arrival and departure, number of rooms, room type | splitting into room nights, stays that cross a month-end |
| Channel / source / tour operator | channel breakdown and commission |
| Status (active, cancelled, no-show) | cancellation and no-show rates |
| Amount, currency, tax included or not | room revenue, currency conversion |

**Why the cancellation date matters.** Last year’s OTB on the same day needs to know whether each booking existed then: created, and not yet cancelled. Without a cancellation date in the export, the comparison can’t be rebuilt retrospectively; the screen stores a nightly snapshot from day one and says the comparison is partial until a year has passed.

Foreign-currency contracts are converted at that night’s rate, with the rate shown. OTA monthly commission invoices are set against the screen’s calculation line by line. Every screen shows its last refresh time, and panel notes stay separate from source data.

This screen isn’t a booking engine, PMS or channel manager; it reads their data (what each layer does: [hotel booking software](https://oguzerol.com/en/hotel-booking-software/)).

The room-by-day grid is a separate screen, on the [hotel room occupancy page](https://oguzerol.com/en/hotel-room-occupancy-tracking/).

## What do front desk, sales, general manager and owner each see?

Everyone sees what their job needs: the front desk doesn’t see revenue, sales doesn’t see costs, the owner sees everything. The starting table I’d suggest:

| screen / field | front desk | sales | general manager | owner |
| --- | --- | --- | --- | --- |
| Today’s and tomorrow’s arrivals and departures, occupancy | yes | yes | yes | yes |
| No-show list (by reservation number) | yes | yes | yes | yes |
| OTB curve and last-year comparison | no | yes | yes | yes |
| ADR, RevPAR, room revenue by channel | no | yes | yes | yes |
| Commission rates, net revenue, net ADR | no | yes | yes | yes |
| Tour operator contract rates | no | yes | yes | yes |
| GOPPAR and monthly costs | no | no | yes | yes |
| Users and permissions | no | no | no | yes (or someone they authorise) |

The no-show list is open to front desk and sales because reporting a no-show to an OTA, and disputing its commission, has to happen within the period set in your contract. The yes/no choices are my suggestion; what doesn’t change is that they live in one written table applied to every screen, report and export. I covered field-level hiding and the audit trail of permission changes in depth on the [expense permissions and reporting screen](https://oguzerol.com/en/expense-permissions-reporting-screen/) page; the same structure applies here.

**Guest personal data doesn’t enter the report.** Counting room nights, channels and amounts needs no guest name, phone, ID or email. If the export contains them, they’re dropped on import and never written to the database; better still, the export template leaves them out. Matching uses the reservation number, and guest names stay in the PMS. This follows the data minimisation principle: personal data limited to what’s necessary for the purpose ([GDPR Article 5(1)(c)](https://eur-lex.europa.eu/eli/reg/2016/679/oj)). If you want a breakdown by guest country, only the country code is imported.

Commission rates are dated: a renewed contract’s rate goes in with a start date, past months keep the old rate, and the change is logged.

**In Turkey**, the same minimisation principle is in the data protection law, KVKK ([Law No. 6698, Art. 4(2)(ç)](https://www.mevzuat.gov.tr/mevzuatmetin/1.5.6698.pdf)), and the accommodation tax is shown separately on the invoice and excluded from the VAT base ([Law No. 6802, Art. 34, as amended by Law No. 7194, Official Gazette 7 Dec 2019](https://www.resmigazete.gov.tr/eskiler/2019/12/20191207-1.htm)), so room revenue is defined net of both.

## What does AI do on this screen, and what doesn’t it do?

AI does two things here: it drafts the morning summary and explains an anomaly a rule has flagged. The numbers come from the table, not from the model. The general manager’s morning summary looks like this (sample data):

> Yesterday: occupancy 74%, ADR 3,210, RevPAR 2,375. In the last 24 hours, 19 room nights were booked and 34 cancelled; 26 of the cancellations came from OTA A and fall in week 3 of next month. Over the last 30 days, OTA A cancellations averaged 7 room nights a day.

Five rules sit behind that text:

1. **A rule finds the anomaly**, e.g. “flag when a channel’s 24-hour cancellations exceed 3 times its 30-day daily average and amount to at least 10 room nights” (my starting threshold, tuned to your data; the floor stops 2 cancellations from setting off a small channel that averages half a cancellation a day). AI describes which week and room type the flagged cancellations cluster in, and whether it looks like a group cancellation.
2. **The table calculates the numbers.** The model writes the sentence; each number is checked against the table, and on a mismatch the table is shown instead.
3. **No row reaches the model without passing the permission filter.** The front desk’s summary is built from occupancy and arrival counts; revenue never reaches the model, so it can’t appear.
4. **No guest data goes to the model**, only aggregates and channel names; for column mapping it sees the file’s column headers, never its rows.
5. **AI doesn’t change rates or decide.** “Discount OTA A for week 3” is a call for someone who knows the contracts.

I also give AI two low-risk jobs, and in both a person has the last word:

- **Channel name mapping.** When an unmapped name arrives from the channel manager (“Booking.com Mobile”, say), AI suggests “probably OTA A” to sales. Nothing is assigned to a channel until sales confirms.
- **Tour operator spreadsheet column mapping.** If the operator’s file says “Arrival Date” one month and “Check-in” the next, AI looks at the column headers only and suggests which column maps to which field; row contents, guest names included, never go to it. The file isn’t imported until the mapping is approved.

The screen works without AI too: the threshold rule and a template produce most of the summary.

## Where does the morning spreadsheet break?

A morning report exported from the PMS and assembled in a spreadsheet works for one person glancing at one hotel once a month. Where it breaks is specific:

- **Today’s file overwrites yesterday’s:** yesterday’s OTB isn’t kept, so last year’s comparison can’t be built.
- **Night-splitting, booking matching, dated commission rates and channel mapping are done by hand every month;** forget one and the report is quietly wrong.
- **Everyone sees everything, or gets a separate file.** A daily front-desk copy with revenue columns hidden is a chore, and hidden columns hide nothing.

In an app, the defined business rule is applied as data comes in and runs every morning without anyone having to remember it.

## If your PMS reports or a revenue management system are enough, you don’t need this screen

If your PMS gives you a channel production report, OTB and pickup, and one person reads them, use those to the full first. If the PMS report is gross only, adding the contract commission rate as a column to the monthly export gives an approximate net view and is a simple start; it doesn’t capture rates that vary by booking. A revenue management system already does pricing and forecasting; a second screen doing the same job means arguing over two numbers.

My own judgement: for a single property selling mostly through one channel, with only the owner reading the report, this screen is unnecessary. It makes sense when data sits in several places, the owner wants a net view that a single commission column can’t give (rates differ by channel, change with contract dates and must be checked against the monthly invoices), different roles need different widths of the same report, the PMS report can’t follow your definitions, or several properties roll up into one table.

## How do we start, who owns the data and code, and how do people sign in?

The first step isn’t software; it’s your morning report: who produces it, from which PMS screen, who reads which number to decide what. I check your PMS and channel manager exports for fields, cancellation dates and retrieval method. Bring a sample reservation export from your PMS, your channel commission contracts (OTAs and tour operators) and today’s morning report. The output is written: metric definitions (what room revenue covers, which date), the channel mapping table, commission rates with start dates, the roles table and the data source. If you have a monthly budget or target, actual-versus-budget is added to the same table as a column.

A mistake I often see in web projects is trying to put every piece of data on the dashboard until nobody can read it. Here that would mean launching twenty metrics, four roles and the AI summary in the first version. My order:

1. Occupancy, ADR, RevPAR and the channel table for one role (general manager), checked against your spreadsheet for the first month.
2. Net-of-commission revenue, cancellation and no-show rates, the roles table.
3. OTB, pickup and last-year comparison.
4. AI morning summary and anomaly explanations.

**Data and code.** The app runs on a server (a rented virtual server, VPS) that can be opened in your hotel’s name. The data is yours, exportable in full as Excel or CSV; the backup approach is written down in the first step’s output. There’s no per-user licence; the cost is the server fee plus maintenance, and in a small or mid-sized team adding users doesn’t change it. The source code sits in a repository you can access, with run instructions, a dependency list and known limitations; keys and accounts are in your name. The screen handles no payments or guest personal data; if scope changes that, access, security, hosting and maintenance are assessed separately.

**Sign-in.** Everyone has their own account; I document the sign-in method and user management in the first step’s written output. The owner, or someone they authorise, assigns roles, and every assignment is logged.

**Changing PMS or channel manager.** Report history and definitions stay in your database; the import is rebuilt for the new system’s export, and if channel names or room type codes change, the mapping is agreed in writing as in the first step.

Tell me through the [contact page](https://oguzerol.com/en/contact/) who produces your morning report, from which PMS, and who looks at which number; in the first meeting we draft your metric definitions and roles table.

## Frequently Asked Questions

### Which PMS or channel manager does it work with?

It depends on the export or connection your PMS and channel manager offer; I don’t promise anything before seeing it. In the first step I document which fields come through and how; without a connection, a regular file export works.

### Can we change rates or allotments from the panel?

No. The screen reads your PMS and channel manager data and writes nothing back; rates and allotments stay in the channel manager. Panel notes are separate app records. Writing back would need the system’s supported operations, permissions and change controls assessed separately.

### How is ADR calculated for rates that include breakfast?

Separate the breakfast portion from room revenue, or a channel selling room-and-breakfast looks pricier than one selling room only. The split follows your decision or your PMS’s package rule, is written once, shown next to the formula and applied to past months too.

### We have several hotels. Can we see each one and the total?

Yes. Property becomes a dimension in the roles table: each general manager sees their hotel, the owner sees all and the total. For the total to be right, room revenue, channel mapping and cancellation definitions must match across properties; we write them in the first step.

[Back to top ↑](https://oguzerol.com/en/hotel-reservation-records-reporting-screens/#icerik)

## You may also find these useful

[How to Choose Hotel Software: PMS, Channel Manager, EngineLooking for hotel software? First separate three systems: PMS, channel manager and booking engine. What each brand does and what to ask a vendor.](https://oguzerol.com/en/hotel-booking-software/)[WhatsApp Automation for Hotel Rates and BookingsExplore a hotel WhatsApp workflow for rates, availability and booking requests. See how system integration and reception handover could work at your property.](https://oguzerol.com/en/hotel-whatsapp-booking-automation/)[Check Conflicts in Appointment and Resource PlanningCheck Excel or Google Sheets appointments against room, vehicle or staff capacity in a custom screen that accounts for durations and preparation gaps.](https://oguzerol.com/en/appointment-resource-planning-app/)

[Browse all articles →](https://oguzerol.com/en/articles/)

WHAT YOU CAN ASK FOR

## How do I work?
Work-hour packages

Tell me about your business and what you need on WhatsApp or by phone; we agree on **a work block of somewhere between 5 and 40 hours** and I start doing what is needed. What you get is not a calendar window — it is net working hours spent directly on your business. I can use 40 hours working three days straight, or deliberately spread it out and finish it over a year — whatever the work calls for. I do not spend my time estimating how long something will take, I spend it doing the work; every hour I spend leaves a lasting result in your business. We keep going for as long as you find it useful.

WORK BLOCKS

## Why not monthly?
Is 40 hours a week?

On a fixed monthly fee both sides are watching the wrong thing: you watch a fixed cost, the other side watches how many more contracts like this they can line up. Working by the hour puts us both in front of the same thing — the real value of the work that got done. I know not having an upfront answer to "how much will this cost in total?" is the natural cost of this model. But instead of paying a fixed fee for months to a setup that is not producing results, you only pay for the qualified time spent on your work — and you see exactly where that time went, start to finish. That is why my clients keep coming back.

5hours300€ + VAT60€ per hour[Choose this block](https://wa.me/905496546489?text=Hi%2C%20I%27d%20like%20info%20about%20the%205-hour%20work%20block.)

10hours500€ + VAT50€ per hour[Choose this block](https://wa.me/905496546489?text=Hi%2C%20I%27d%20like%20info%20about%20the%2010-hour%20work%20block.)

20hours800€ + VAT40€ per hour[Choose this block](https://wa.me/905496546489?text=Hi%2C%20I%27d%20like%20info%20about%20the%2020-hour%20work%20block.)

40hours1,400€ + VAT35€ per hour[Choose this block](https://wa.me/905496546489?text=Hi%2C%20I%27d%20like%20info%20about%20the%2040-hour%20work%20block.)