When a guest cancels on a room type you had closed, Booking.com can reopen that room automatically. Here is why it happens and how to stop it reselling a room you meant to keep off the market.
A cancellation on a room type you had deliberately closed can quietly reopen that room for sale again, because allotment and stop-sell are not always the same lever behind the scenes. This article explains the mechanism and walks through how to check and correct it before the room gets rebooked.
You close a room type deliberately, for maintenance, a long-stay guest, or simply to hold it off the market, and the closure holds for a while. Then a different reservation on that room type gets cancelled, and shortly afterward the room becomes bookable again, even though you never reopened it yourself.
From the outside this looks like the system undid your decision for no reason. In practice, it is usually a specific behavior around how allotment is restored after a cancellation, interacting with a closure that was applied on top of the allotment rather than replacing it.
Allotment is the number of rooms available to sell for a given room type and date, and stop-sell is a separate instruction that blocks sale regardless of allotment. Some setups restore allotment automatically when a booking against that allotment is cancelled, on the logic that the room is now free again, without checking whether a stop-sell or manual closure was also meant to apply to it.
If your closure was applied as a reduction in allotment rather than as an explicit stop-sell, a cancellation can effectively hand that allotment back, and depending on your settings that can be enough to make the room bookable again even though your underlying intention, to keep it closed, never changed.
Look at the specific cancellation and the room's current state together, rather than only the room's current state in isolation.
Read-back verification applies to stop-sell the same way it applies to rates and availability: the actual state on the channel is read back and compared against what you intended, so a room that reopens unexpectedly after a cancellation is reported as a change to investigate rather than discovered through a new booking.
Activity history records who or what changed availability on a room, across a long list of action types, which makes it straightforward to confirm whether a cancellation, a person, or an automated rule reopened it. You can explore both on the public demo at try.primehostpartners.com.