What is RevPAR, and do you need it with a single property?
· 5 min read
RevPAR (revenue per available room) is the revenue attributable to one available unit in a given period — whether or not it was sold. You calculate it by dividing accommodation revenue by the number of unit-nights that were on sale. It combines two things that mislead when read separately: price and occupancy.
Why anyone invented it
Because price alone and occupancy alone can be pushed in opposite directions. Double your price — the average rate looks excellent and the property stands empty. Halve it — occupancy looks excellent and there is no money. Each number on its own lets you tell any story you like.
RevPAR takes that option away, because it falls both when you sell too cheaply and when you sell too little. That is its only real virtue, but it is a real one.
How it is calculated
Two equivalent ways. Either divide revenue by the number of available unit-nights, or multiply the average rate of a sold night (ADR) by occupancy. With one apartment available for thirty nights, fifteen of which sold at PLN 400, revenue is PLN 6,000 and RevPAR is PLN 200.
The same figure comes out of twenty nights sold at PLN 300: revenue PLN 6,000, RevPAR PLN 200. That is exactly the point — two different ways of running a property, one identical result — and only a comparison with the previous month tells you whether anything improved.
Is it useful with a single property?
Less often than its popularity suggests. RevPAR is a comparative tool: it makes sense when you set month against month, year against year, or your hotel against a competing one. With one apartment and a dozen or so bookings a month, the difference between PLN 200 and PLN 215 of RevPAR sits inside the noise — one extra booking or one cancellation moves the number without anything changing in how you run the place.
It does earn its keep when you have several units at different prices and want to know which one actually earns. A PLN 200 room sold 90% of the time beats a PLN 500 apartment sold 30% of the time — and only RevPAR makes that visible.
When we show it, and when we do not
We show it exactly when we have something to compute it from — that is, once you upload your completed bookings. Before that we do not show it at all, and it is worth knowing why, because it explains everything else.
A connected iCal calendar tells us which nights are taken and which are free. It does not carry amounts. The other money we know is the price you approved in the panel — and that is not the same as the price the guest paid. Between the two sits everything we cannot see: whether you actually entered that price on the portal, what the commission was, whether the booking went through, whether there was a long-stay discount.
We could multiply approved prices by occupied nights and call it RevPAR. It would look professional, and it would be a number about your property that nobody — ourselves included — could verify. We still do not do that. The same principle that stops us forecasting revenue growth is set out in our methodology.
What changed is something else: you can upload a file of bookings from your own system — with the prices you actually got. At that point revenue stops being our guess and becomes your fact, and the panel computes ADR, occupancy and RevPAR from it. We never mix the two sources: not one price that we proposed and you merely approved goes into those numbers.
This post originally explained why we do not show RevPAR. We are not walking that back — its premise changed, not its principle. The refusal was about inventing revenue. Once revenue stopped being invented, the grounds for refusing ran out.
What we show regardless
Things we can count honestly from the calendar alone, with no import:
- unsold capacity — how many nights in your calendar stayed empty and what that comes to at your own base rate; we deliberately call it capacity rather than „lost profit”, because we do not know whether those nights could have been sold;
- the conservative counter — nights sold where the approved price was higher than what you charge for comparable nights without our recommendation;
- your calendar’s rhythm — which days of the week sell better, how far ahead your guests book, and where the gaps between stays appear.
If you want to calculate it yourself
A spreadsheet and two columns will do: accommodation revenue for the month, and the number of nights the unit was on sale. Divide one by the other. Two rules matter more than the number itself: always calculate it the same way (with portal commission or without — just be consistent), and only ever compare the same month year on year, because August and November have nothing to do with each other.
One closing caveat: RevPAR measures the past. It will not tell you what to charge for the night of 15 August — that is a question about the future, and it is answered from the calendar, the season and events, not from last month’s summary.