The night audit closes the books and loses the reasons

Every hotel already runs one process that stops the day and writes it down. The night audit posts the charges, reconciles the ledger, rolls the business date and prints the day's figures. It is the closest thing in the building to a timestamped snapshot of the whole operation, and it is treated as bookkeeping.

The one moment the day stops moving

Occupancy at four in the afternoon is a guess. Occupancy after the close is a fact. Rates stop changing, room moves stop, the arrivals list is final, and the day becomes an object you can point at. That property is rare in hotel operations, where most numbers are still moving while you read them, and here it costs nothing, because the close already happens.

The report survives, the state does not

What comes out of the close is a handful of aggregates. What goes into it is far richer: which rooms were held and then released, which rates were overridden and by whom, which arriving guest the system decided was new, which room sat out of order and for how long. Once the ledger balances, that detail has done its job and nobody keeps it.

Calling that negligence misses the point. The close was built to produce a balanced ledger and it does that well. It was never asked to produce an explanation, so it does not retain the things an explanation needs.

Not knowing why is a storage problem

Ask a revenue manager why last week moved and you get a reconstruction: memory, a few emails, a sense of what the market was doing. The usual response is to buy a better report, which puts a new surface on the same aggregates. No amount of analysis recovers a variable that was never written down. The question is hard because the day was summarised before the reasons were saved.

You cannot aggregate your way back to a field you never stored. A prettier report of the same totals answers exactly the questions it answered before.

What is worth keeping, and why each line pays

• Every rate override, with who made it and against which recommendation. Without the author, a run of overrides reads as noise rather than a standing disagreement between a person and a model.
• Inventory that was held and released, not only what was sold. A room blocked for an enquiry that never closed looks identical afterwards to a room nobody wanted.
• The identity decision taken at arrival: whether the system treated this guest as new. That one field is what makes repeat behaviour countable later.
• Out-of-order minutes per room, with the reason. A small set of rooms usually carries a disproportionate share, and you cannot name them without the rows.
• The channel each booking carried at the close, not the one it reads today, because channel attribution gets rewritten by later edits.

Hang it on the close, not beside it

A new capture ritual competes with work that already fills the shift, which is why most of them quietly stop. The close has an advantage nothing else in the building has: it is already staffed, already daily, and already has one person whose job for the next hour is to run it. Appending writes to a process that runs anyway is the cheapest instrumentation available to you.

Run it in parallel for two cycles and leave the existing report untouched. The test is not whether anyone likes the new screen. The test is whether the next variance question gets answered out of stored rows instead of a reconstruction.

What the channel mix hides once you can see contribution per booking →

What this does not claim

No figures appear above. The ones that would matter here are a property's own, and inventing them would defeat the purpose. This also says nothing about what any particular property management system keeps or discards: that varies by vendor, by version and by what your contract lets you export, and it is a question to put to the vendor rather than to assume. The claim is narrower. The daily close is a capture point you already pay for, and most of what passes through it is not kept.