Somewhere in your hotel there is a room nobody can sell, and the status a housekeeper picked for it this morning is quietly editing the numbers you will report at the end of the month. Out of order and out of service look like the same thing from the corridor. Both mean a room a guest cannot have. Both get set by the same people, usually in a hurry, usually from a phone. In your property management system they behave completely differently, and only one of them changes the size of your hotel.
That difference is not a technicality. Occupancy and RevPAR are both fractions with rooms available on the bottom, so anything that changes the number of rooms available changes both metrics without a single extra booking being made. Out of order shrinks that denominator. Out of service does not. Which means the choice between them is not a housekeeping decision at all, it is a reporting decision, and it is being made dozens of times a month by people who have never been told that it is one. Anyone who reads a daily flash report out of a revenue management system is reading a number that this choice has already moved.
Then it gets more interesting. Your property management system and your benchmark do not agree about how to handle these rooms. The system removes them. The benchmark refuses to. So the occupancy your duty manager reads at eight in the morning and the occupancy your owner sees in the competitive report are calculated on different denominators, and nobody in the building is told which one is which.
Two Statuses and One Difference That Matters
Start with what the vendors actually say, because on this point the documentation is unusually consistent and unusually ignored.
Out of order is for a room that cannot take a guest for a prolonged period. A burst pipe, a refurbishment, a floor that is being replaced, a room being used to store furniture during a renovation. The room comes out of sellable inventory. It cannot be assigned. It is gone, for the purposes of the system, until somebody puts it back.
Out of service is for a room with a short problem. A television that will not switch on, a shower door off its runner, a stain that needs a second pass before anyone sees it. The room is blocked from immediate assignment but stays in inventory, and in most systems it can still be sold if the night gets tight and the problem is genuinely cosmetic.
The distinction that matters is not repair duration, though duration is the usual proxy. It is inventory. One status tells the system the hotel is temporarily smaller. The other tells the system the hotel is the same size but this particular room needs attention first.
Almost every operational problem in this article comes from staff choosing between those two on the basis of how broken the room feels, rather than on the basis of what they want the system to believe about the size of the hotel.
What Out of Order Does to Your Inventory
Oracle's OPERA documentation puts it about as plainly as vendor documentation ever manages. Rooms placed out of order no longer figure in availability statistics, are unavailable to sell, and are deducted from inventory. It then gives the example that makes the consequence concrete: on a hundred room property with five rooms set out of order, one hundred percent occupancy is reached at ninety five rooms, not a hundred.
Read that twice, because it contains the entire argument. Full occupancy now happens five rooms earlier. The hotel is, for reporting purposes, a ninety five room hotel. Every ratio built on rooms available has just moved, and the movement is upward.
Two Vendors, One Rule
This is not an Oracle quirk. Mews documents the identical behaviour and is blunter about the consequence. Its occupancy calculation is published as occupied spaces divided by spaces, where spaces is defined as total spaces less out of order. Its help pages say directly that out of order reduces availability and affects RevPAR, that out of service does neither, and that staff should avoid using out of order unless there is no other option.
That last line is worth sitting with. A property management system vendor is telling front line staff to avoid one of its own status codes wherever possible. Vendors do not usually write that about a feature unless they have watched it cause trouble.
Two independent systems, built by different companies for different segments, land on exactly the same rule. Out of order takes the room out of the denominator. Out of service leaves it in. If you use a different system, check it, but expect the same answer, because this convention long predates both of them.
What Out of Service Does Instead
Out of service is the quieter status and the one most properties underuse. The room stays in inventory. Availability does not move. Occupancy and RevPAR do not move. The front desk can still see the room and, if the problem is minor and the night is full, can still put somebody in it.
Oracle describes it as short term maintenance mode, notes that out of service rooms remain in the total room availability count, and adds that front desk staff can return them to availability once the repair is done. Mews describes it as blocking a room for an immediate assignment, for example a minor repair, and states that it affects neither RevPAR nor ADR.
In practice out of service is the correct status far more often than it gets used, for a simple behavioural reason: it feels weaker. A housekeeper looking at a room with a broken lamp and a torn curtain wants to communicate that the room is a problem, and out of order sounds like it communicates that more forcefully. The status codes are read as a severity scale rather than as an inventory instruction, and that misreading is where the reporting damage begins.
The Denominator Is the Whole Story
It is worth writing the two formulas out, because almost everyone knows them and almost nobody thinks about what sits underneath.
Occupancy is rooms sold divided by rooms available. RevPAR is total rooms revenue divided by rooms available. Both have the same term on the bottom. Neither has any term that reflects whether a room was blocked, why it was blocked, or how long it stayed that way.
So when a status code edits rooms available, it edits both metrics at once, in the same direction, without touching anything you would normally think of as performance. You did not sell more rooms. You did not charge more. You made the hotel smaller on paper, and both ratios improved because their denominator got smaller.
This is why the choice cannot be delegated to whoever happens to be holding the phone. It is the only routine operational action in a hotel that changes a headline metric without any commercial event occurring. A rate change requires somebody to change a rate. A booking requires a guest. Blocking a room requires a housekeeper and two taps.
USALI Will Not Let You Shrink the Hotel
Here is where the two worlds separate.
The Uniform System of Accounts for the Lodging Industry is the accounting framework that underpins hotel financial reporting almost everywhere, and it is what your owner's accountant, your asset manager and your lender's analyst are working from. Under USALI, rooms available is total room inventory less rooms that are not available for sale. The question is what counts as not available for sale, and the answer is much narrower than operators expect.
Rooms taken out of salable inventory for less than six consecutive months, because of a temporary fault or a renovation, are classified as rooms out of order and sit inside vacant rooms. Vacant rooms is rooms available less rooms occupied. In other words, a short term out of order room is still counted in rooms available. It has not left the hotel. It is simply a room that was available and did not sell.
Rooms leave the available count only in a short list of situations: extended closures of six consecutive months or more, usually as a result of something outside the hotel's control such as a fire, a storm or an earthquake; rooms designated for permanent house use for six months or more; and seasonal closures where the whole operation shuts for at least thirty consecutive days.
The logic is not arbitrary. If a hotel could remove rooms from its own denominator whenever it liked, every occupancy figure in the industry would become uncomparable, and any property having a bad quarter could improve its statistics with a maintenance flag. The six month test exists to make that impossible while still allowing genuinely lost inventory to be removed.
STR Will Not Adjust Your Supply Either
The benchmark says the same thing, in less abstract language.
STR's benchmarking guidelines require full room night availability to be reported for every hotel, which they define as the number of rooms at the property multiplied by the days in the period. They then state explicitly that there should be no adjustment in room availability reported to STR if rooms are temporarily out of service for renovation for a period of less than six months. If rooms are permanently removed, management is told to contact STR so the room count can be changed. Extended closures beyond about six months, whether from renovation or from a hurricane, earthquake, fire or similar, get flagged so the inventory reduction is handled deliberately. A property that closes entirely for more than a calendar month is marked as temporarily closed and drops out of the competitive set for that period.
Notice how carefully every route out of the denominator is gated. You can reduce your supply, but only by telling the benchmark and only for reasons that will not recur every month. What you cannot do is let a room status code do it silently.
So both authorities that matter outside your building have independently concluded the same thing, and both have concluded the opposite of what your property management system does by default.
The Gap This Opens, in Numbers
Take a hundred room city hotel. Five rooms are out of order for a month while a bathroom refit works its way down one side of the third floor. The hotel sells sixty rooms a night on average at an ADR of a hundred and fifty euro, so it takes nine thousand euro of rooms revenue a night and two hundred and seventy thousand across the month.
Two sets of numbers now exist for the same hotel, the same month and the same revenue.
| Measure | As your PMS reports it | As USALI and STR require |
|---|---|---|
| Rooms available per night | 95 | 100 |
| Rooms sold per night | 60 | 60 |
| Occupancy | 63.2% | 60.0% |
| RevPAR | 94.74 | 90.00 |
| ADR | 150.00 | 150.00 |
The hotel earned exactly the same money in both columns. Nobody sold anything extra. But the internal report shows occupancy three point two points higher and RevPAR four euro seventy four higher, an overstatement of a little over five percent on the metric most likely to be quoted in a board pack.
ADR is untouched, which is what makes this so easy to miss. ADR divides by rooms sold, not rooms available, so it behaves identically in both columns. A manager sanity checking the numbers sees ADR agreeing perfectly and reasonably assumes everything else agrees too.
Now put that alongside a competitive set running at ninety euro RevPAR. Your STR report, built on a hundred rooms because that is what the guidelines require, shows you at ninety and gives you an index of one hundred. You are performing exactly at market. Meanwhile every internal report all month has been showing ninety four seventy four, and the natural reading of that number is that you are beating the market by five percent. You are not. You are level, and you have spent a month believing otherwise.
Where the Gap Turns Up Later
A five percent discrepancy that nobody notices is harmless right up until the moment somebody compares two documents. Then it turns up in a handful of predictable places, usually at the worst time.
Owner reporting is the most common. An owner or asset manager reading a monthly pack against a benchmark report will eventually ask why the operator's occupancy does not match the one in the competitive data. The honest answer, that the two are computed on different denominators because of maintenance blocks, is perfectly defensible and sounds terrible when given for the first time in a meeting rather than written into the reporting notes in advance.
Budget variance is the next. If your budget was built on full inventory, which it almost certainly was, and your actuals are being reported on reduced inventory, then your occupancy variance is partly an artefact. You will spend time explaining a favourable variance that did not happen.
Management agreement performance tests are the sharpest case. Where an agreement measures performance against a competitive set, the figure that counts is the one in the benchmark, computed on full supply. An operator who has been reading inflated internal numbers has no early warning that the tested number is weaker, because the number they see every day is the flattering one.
And then there is the simplest one. Two managers, one quoting the PMS and one quoting the benchmark, disagreeing about how the hotel is performing and both being right.
The Status That Hides Your Own Problem
There is a deeper reason USALI insists on keeping these rooms in the denominator, and it is worth understanding as an operator rather than as an accountant, because it changes how you feel about the status.
When a room is out of order and out of the denominator, the revenue it failed to earn disappears from your reporting entirely. There is no shortfall, because the room was never counted as capable of earning. The maintenance backlog costs you nothing that any report can show.
Keep the room in the denominator and the arithmetic becomes uncomfortable in exactly the right way.
What Five Rooms Actually Cost
Five rooms out of order for thirty nights, at a market RevPAR of ninety euro, is thirteen thousand five hundred euro of revenue the hotel did not earn. That figure is real whether or not anyone chooses to calculate it. Report on ninety five rooms and it vanishes. Report on a hundred and it shows up as depressed occupancy and depressed RevPAR, which is precisely what it is.
Framed that way, the accounting convention stops being a compliance nuisance and starts being a management tool. The refurbishment that has been running two months longer than planned has a number attached to it. The room that has been blocked since spring because the replacement bath panel never arrived has a number attached to it. Somebody can put those numbers next to the cost of expediting the part.
Out of order, used loosely, is the only status in a hotel that makes its own cost invisible. That is not a reason never to use it. It is a reason to use it deliberately, with a reason and a date attached, and to keep measuring the hotel at its real size while you do.
Reason Codes, and Why Maintenance Is Not One
Both major systems support reason codes on these statuses, and OPERA ships the concept as configurable out of order and out of service reasons precisely so the blocks can be analysed later. Most properties either leave the list at the defaults or fill it with a single catch-all.
A reason code that says maintenance tells you nothing. Every block is maintenance. The question a reason code should answer is what kind of failure took this room away, so that a year of blocks can be read as a pattern rather than as noise.
A list worth having distinguishes between causes with different owners and different fixes. Water damage and plumbing. Heating, ventilation and air conditioning. Electrical. Furniture and fittings awaiting replacement. Deep clean or odour treatment. Planned refurbishment. Damage caused by a guest, which may be recoverable. Storage or contractor use, which is not maintenance at all and is the category most often hidden inside it.
The value shows up at the end of a season. Twelve blocks on the same wing for water damage is a building problem, not a housekeeping one. Forty blocks a year for furniture awaiting replacement is a procurement problem. A quarter of your out of order nights turning out to be contractor storage is a conversation about whether the refurbishment programme is being managed to a schedule.
None of that analysis is possible if the reason field is optional, and none of it is reliable if the list is short enough that everything lands in the same bucket.
The Room That Went Out of Order in March
Every hotel over a certain age has one. A room blocked months ago for a reason nobody currently on shift remembers, with no expected return date, which everybody has stopped seeing.
Systems will let you do this. Mews requires a start and an end date and time for an out of order block, and flips the room to dirty automatically when the block ends, which is a genuinely useful piece of design. Other systems are looser and will happily accept an open ended block. Either way, the discipline that matters is not technical, it is that somebody looks at the list.
A weekly review of every blocked room, with three questions, takes about ten minutes at a property of any size. What is stopping this room selling. Who owns getting it back. When is it coming back. A block that fails the third question is not a maintenance issue, it is a management issue, and it has been costing roughly one RevPAR per night since the day it started.
The long term blocks are also the ones that eventually cross the six month line, at which point they stop being an internal reporting quirk and become something you are obliged to tell your benchmark about. Nobody discovers that on time by accident.
Who Should Be Allowed to Press It
If setting a room out of order changes a headline metric, then it deserves the same treatment as any other action that changes money, and at most properties it does not get it.
A split that works in practice gives everybody the ability to stop a room being sold, and very few people the ability to change the size of the hotel. Housekeeping and maintenance staff can set out of service freely, because that status blocks assignment without touching the denominator, and the cost of an unnecessary out of service block is close to zero. Out of order requires a duty manager, a head of maintenance or a general manager, comes with a mandatory reason from the list, and carries an expected return date that somebody has actually thought about.
The point is not to slow down the housekeeper who has found a flooded bathroom. The point is that the housekeeper's job is to take the room out of service, immediately and without asking anyone, and somebody else's job is to decide whether the hotel just got smaller.
The audit trail matters as much as the permission. Without a record of who blocked which room, when, for what reason and for how long, none of the analysis in the previous two sections is possible, and an occupancy discrepancy discovered in November cannot be traced back to a decision made in June. Room blocking has historically been one of the last routine actions in a hotel with no user level logging behind it, which is why we added activity logging for out of order, out of service and blocked dates in Prostay's August 2026 release. The general principle stands regardless of system: if an action can move RevPAR, it should leave a name and a timestamp.
When a Room Genuinely Crosses the Six Month Line
Sometimes a room really is gone. A fire takes a floor. A structural problem closes a wing. A conversion turns four rooms into two suites and a plant room. In those cases the inventory reduction is real, and both the accounting standard and the benchmark have a route for it.
Under USALI those rooms move out of rooms available, as extended closed rooms where the closure runs six consecutive months or longer, or as permanent house use where rooms are given over to staff or operational use for six months or more. STR expects to be contacted so the room count can be adjusted, and handles extended closures and full property closures with their own treatments, including marking a property as temporarily closed if the whole building goes offline for more than a calendar month.
Three practical points. First, this is a deliberate act of communication, not a status code, so somebody has to own it. Second, changing your room count changes your history, so the reduction should be dated and documented well enough that a comparison against last year still makes sense. Third, the moment a temporary block starts looking permanent is the moment to start the conversation, not six months later when somebody notices the room has been dark since spring.
A Policy You Can Adopt This Week
None of this requires a project. It requires a page of policy and a recurring meeting.
Write down which status means what, in inventory terms rather than severity terms. Out of service means the room cannot be assigned right now. Out of order means the hotel is temporarily smaller. Brief housekeeping and maintenance on that framing specifically, because the severity reading is the default and it is wrong.
Make out of service the default for anything under a week. If the fix is a part, a paint touch up, a deep clean or a contractor visit that is already booked, the room stays in inventory. Out of order is for rooms that will not take a guest for a prolonged period.
Restrict out of order and require a reason and a return date. A short list of real reasons, mandatory, plus a date somebody has committed to.
Review every block weekly. Ten minutes. What is stopping it selling, who owns it, when is it back. Anything without an answer to the third question gets escalated.
Decide which occupancy you report, and say so in the notes. If you report internally on reduced inventory, state it on the report, so nobody is comparing it against a benchmark figure computed on full supply without knowing. Better, report both while any block is open, and let the difference be the visible cost of the maintenance backlog rather than a discrepancy somebody finds later.
The two statuses will keep looking identical from the corridor. They will keep being set by people carrying cleaning supplies rather than reports. That is fine, and it is why the fix is a definition and a permission rather than a piece of software. Get the definition right and the difference between the hotel you are running and the hotel you are reporting closes on its own.
