Dynamic pricing and RevPAR for rentals in Spain
What RevPAR measures, how fixed, seasonal, rule-based and dynamic pricing compare, and where pricing fails: gaps, minimum stays and sync delays.
RevPAR is the most quoted metric in holiday rentals and the most misused. It joins in one number what you charge per night and how many nights you sell, which is why it shows things the average rate hides. Here is how to read it, how to compare the ways of setting prices, from a fixed rate to dynamic pricing, and where almost every pricing operation fails, whatever software you use.
What RevPAR measures and what ADR hides
RevPAR (revenue per available night) is calculated by dividing accommodation revenue by the nights the flat was available to sell. ADR (average daily rate) only says at what price the occupied nights were sold.
An example with round numbers. In a month with 30 available nights you sell 20 nights at an average rate of 100:
| Metric | Calculation | Result |
|---|---|---|
| Occupancy | 20 nights sold out of 30 available | 66.7 % |
| ADR | Revenue divided by nights sold | 100 |
| RevPAR | Revenue divided by available nights | 66.7 |
The next month you raise the average rate to 120 and sell 14 nights. ADR goes up to 120, but RevPAR drops to 56. The average-rate chart looks like a success while revenue falls.
So reporting ADR to an owner without putting occupancy next to it shows them half the picture.
Every price change is a bet
Raising the rate for a night increases the margin per booking and the risk that it stays empty. Lowering it secures occupancy, but can sell cheaply a date that a last-minute traveller would have paid more for. Neither direction is right on its own. What lets you decide with judgement is knowing how far ahead people book in your market and how that lead time changes by season.
How to compare a fixed rate with dynamic pricing
There are four common ways to price nights. None is the best in the abstract: each fits a different portfolio size and a different amount of management time.
| Approach | How it works | Advantage | Risk | Fits |
|---|---|---|---|---|
| Fixed rate | The same price all year | Simple and predictable | Leaves money on the table in high season and sells little in low season | A single flat with very stable demand |
| Seasonal | Different prices for high, mid and low season | Captures the yearly pattern | Does not react to events or last-minute changes | Small portfolios with little management time |
| Rule-based | Automatic adjustments by lead time, occupancy or day of the week | Reacts without manual work | Rules age if nobody reviews them | Managers who know their market well |
| Dynamic with market data | An algorithm proposes each night's price from demand and competitor data | Spots changes a person does not see in time | Depends on data quality and on someone watching its decisions | Medium and large portfolios |
The jump from seasonal pricing to dynamic pricing is not just about tools. It changes who decides: you move from setting prices to supervising decisions. If nobody has time to review what the algorithm does, a good rule-based setup can earn more than a neglected dynamic one.
What to check before switching
Before moving to dynamic pricing, check three things: that your booking data is reliable, that your channels receive changes on time and that someone will review the exceptions every week. Without that, the algorithm optimises on wrong numbers.
Where does pricing data come from?
Rates, availability, stay restrictions and confirmed bookings have to live in a single system that every channel draws from. With one calendar in the channel manager, another in the PMS and a spreadsheet for direct bookings, you do not have a pricing problem: you have a data problem that will end up looking like one.
The test is immediate. Look up the rate for a night three weeks from now. If you have to check two systems and reconcile them by hand, any algorithm will work on wrong numbers.
Sync delay costs money
Channel connections come in two kinds. API connections push every change the moment it happens and confirm it arrived. iCal connections poll the calendar every so often, often at intervals of tens of minutes.
For availability, that delay causes double bookings. For rates the damage is quieter: you lower the price to fill a gap, the channel takes a while to show it and the booking goes to another listing while your dashboard shows the change as applied.
Where pricing operations fail
Orphan nights
A two-night gap between two bookings, with a three-night minimum stay, can never be sold. No price fills that date while the restriction is active. These gaps appear as soon as occupancy rises and never show in the reports, because they never count as lost bookings.
Minimum stays that outlive their reason
Minimum stays are usually set per season and then forgotten. The four-night minimum that made sense in August is the one creating orphan nights in November. Review minimums on a fixed schedule; do not leave them as permanent values.
Cleaning fees that inflate short stays
A fixed cleaning fee weighs fully on a one- or two-night booking and pushes the final price far above the advertised one. Often it is that surcharge, and not the base rate you keep adjusting, that blocks short bookings.
Rate pushes that fail without warning
Price updates fail because of expired credentials, deactivated listings or a broken mapping after a unit is renamed. The costly part is that these failures almost never show as errors on the dashboards people check every day.
Rate parity with the platforms
What to automate and what to decide yourself
Automate the mechanical work: detecting calendar gaps, reviewing minimum stays on a fixed schedule, checking that every channel push arrived and updating prices daily. These failures happen through forgetting, not through lack of judgement.
Keep the judgement: local events, competitors opening or closing, sudden changes in supply or the dates when the owner uses the flat. No software sees those things by looking at a calendar alone.
How to read the RevPAR trend without fooling yourself
RevPAR can only be compared with itself when the denominator does not change. Adding a flat mid-month, blocking dates for works or an owner's stay change the available nights and move RevPAR without your pricing strategy having changed.
Before drawing conclusions from one month to the next, go through this list:
- ☐ Available nights are the same in both periods, or you have adjusted them.
- ☐ Owner and works blocks are out of the calculation.
- ☐ Revenue is accommodation only, without cleaning or other charges.
- ☐ You compare with the same month of the previous year as well as the previous month.
- ☐ You read RevPAR next to occupancy and ADR, never on its own.
For anyone managing prices for several flats, in the features we are building at Klimpy we describe which part of this work we want to automate. And if your arrivals still depend on a person with a key, the guide to the guest register and its automation explains how to chain booking, registration and access.
Related articles: