What is anomaly detection? Catching the odd number in hotel reports

Anomaly detection is the practice of flagging a number that falls outside the range a business expects for that day, that outlet and that season. In a hotel it turns voids, discounts, minibar revenue or water per occupied room into a short list of questions, not a verdict.

The night audit closes, the reports print, and one line looks wrong: minibar revenue at zero for a room that has been occupied for four nights. Someone has to decide whether that is a system problem, a posting mistake or nothing at all. Anomaly detection is the discipline of deciding which lines deserve that attention before the shift ends. After reading this you will be able to pick a number, build a range from your own history, and run one rule that your team actually trusts.

What is anomaly detection, in plain words?#

Anomaly detection is the practice of flagging a number that does not fit the pattern the rest of the data shows for the same conditions. It answers one question: is this number where it should be, given what day, outlet and season this is?

The mechanism has three parts: a number you record on a fixed rhythm, a range you expect it to stay inside, and a rule that decides who looks when it leaves the range. Everything else is detail. The number can be anything the hotel already tracks, from void value per shift to water per occupied room.

Two ideas must be kept apart. An outlier is a number far from the others in a set. An anomaly is a number that is unexpected for its context. A banquet for 300 people is an outlier on a quiet Tuesday and completely normal for that hotel. The third idea is the alert: the message a person receives when a rule fires.

Anomalies come in three shapes. A single point is one night's minibar revenue collapsing. A context anomaly is a figure that is normal in August and wrong in February. A slow drift is a number that moves a little every week until it is far from where it started, which is the shape most often missed by eye.

Hotels suit this method because the same numbers repeat daily and each has a natural denominator: occupied rooms, covers served, guests in house, nights sold. A number divided by its denominator is comparable across days, which is exactly what a range needs.

Anomaly detection does not explain anything and does not decide anything. It narrows a long report to a short list, and a person supplies the reason. It is also not new: a fixed rule such as "no room may post a negative minibar charge" is anomaly detection, done by hand, and it still catches things.

What does anomaly detection look like in a hotel?#

It looks like a short list of numbers the hotel already produces, each with a range attached. The value is in choosing numbers that have a denominator and a person who can act on them.

Voids and corrections are the classic case: count and value per shift, per outlet and per user. A void is a normal event; a shift whose void value sits far above the same shift on the same weekday is worth a look. Discounts and allowances work the same way, measured as the share of room revenue given away, by rate code and by approver. The question is not whether discounts exist but whether this week's pattern matches the hotel's own policy and its own past.

Minibar and restaurant postings offer cheap wins. A room occupied for several nights with no minibar charge, or a charge posted after the guest has checked out, are both cheap to detect and cheap to check. Utilities per occupied room, water and electricity divided by rooms occupied, is one of the few cost lines a hotel can read daily, and a jump usually points to a leak, a meter read on the wrong day or an irrigation timer. We cover that line in more detail in energy and water per occupied room: daily meter readings a hotel can act on.

House use and complimentary rooms belong on the list too: a count per week, compared with the hotel's own written policy on who may grant them. So do cash overages and shortages per cashier and per shift, and the ageing profile of city ledger accounts, where a single account can quietly grow for weeks.

How do you set a normal range from your own history?#

Take one number, give it one denominator and one period, then look at what that number actually did on comparable days in your own records. The range comes from your hotel, not from an industry benchmark.

Write the definition down before you compute anything: which revenue accounts are included, whether the denominator is rooms occupied or rooms available, and at what hour the day closes. A range built on a shifting definition will fire forever. Compare like with like: group the history by day of week and by month, and build the range from the matching group rather than from the whole year.

Use the middle and the spread, not just the average. The median tells you the typical day; the distance between the quiet days and the busy days tells you how wide the band must be. An average alone hides exactly the swings you are looking for. Start wide and narrow later: a band that fires twice a week in the first month is teaching you where the real edges are, while a band that fires every day is teaching people to ignore it.

Keep two kinds of rule side by side. A fixed limit must never be crossed: a negative charge, a posting after checkout, a zero for an occupied room. A learned band moves with the business. Record every outcome, alert raised, checked, explained, no action, or escalated. That log is what tunes the rule next month, and it is the only evidence that the control works.

For example, a hotel might build a minibar band from the last ninety days of postings per occupied room, then widen it by a margin before switching it on. The number of days is a starting choice, not a standard.

Why do season, groups and holidays break the baseline?#

Because the number stops behaving like the history it was measured against. A range built in a quiet month will fire all summer, and a range built on individual travelers will misfire on group nights.

Season changes both the level and the mix: more rooms sold, different nationalities, different length of stay, different spend per guest. The minibar line of a coastal hotel in July has little in common with its February. Group blocks and allotments move several lines at once. A coach group may take forty rooms and barely touch the minibar, so revenue per occupied room falls while occupancy rises. Neither number is wrong.

Holidays move every year. A religious holiday that fell in one month last year falls in another this year, so the calendar has to be part of the baseline, not an afterthought. Local events, closures and renovations produce legitimate zeros: an outlet closed for refurbishment will post nothing for weeks, and a rule that expects revenue will fire every night.

The practical fix is to segment the range, or to suppress alerts on days the hotel has flagged in advance. Both need a shared exceptions calendar that the night auditor can edit, because the auditor is the person who knows the hotel is hosting a wedding. When a baseline is unreliable, fall back on the fixed limits. A hard rule such as "no posting after checkout" works in every season and needs no history at all.

Why do too many alerts get ignored?#

Because people stop reading a list that is mostly wrong. Every false alert spends the same attention a real one needs, and attention is the scarce resource in a night shift.

This is a trade-off, not a failure. A wide band catches few things and misses small ones; a narrow band catches everything and buries the real signal. The right setting depends on how many alerts the team can actually answer in a shift. Give every rule one named owner and a response time, because an alert addressed to everyone is answered by no one.

Require a written response for every alert, including "checked, explained, no action". The written line is what turns a noisy rule into a tuned one. Review the rules monthly and retire the ones that never produce a useful answer; adding a rule after every incident without removing one is how a control system dies. Split the routing: routine checks stay with the night auditor, while anything touching cash, discounts or a named employee goes to the income auditor and the financial controller. Prefer a few rules that people trust over many that they skim. A hotel with five rules that are always answered has a better control than a hotel with fifty that are not.

Is an alert an accusation against a staff member?#

No. An alert says a number is unusual for its context. It says nothing about who caused it or why, and most first explanations turn out to be a process problem rather than a person.

Check the data before the person: a point-of-sale mapping error, a rate code loaded with the wrong package, a meter read on the wrong date, a group bill split across two folios. These explain a large share of first-time alerts. Then check the process: was the discount within the approver's authority, was the void documented, was the room genuinely empty. The question is whether the control worked, not whether someone is trusted. The mechanics of what the night audit produces before this check are covered in night audit reports explained: trial balance, manager's flash and the exception lists.

Talk to the person with the record in hand and the range visible. An unexplained alert discussed openly is a training moment; the same alert used as an accusation teaches people to hide numbers. Look for patterns across weeks, not single nights. One unusual shift is noise; the same shift drifting every week is a finding.

Keep staff-related records factual and limited to what the investigation needs, and take advice on how personal data of employees may be processed and retained. Hand anything that survives the process check to the income audit, which is built to follow a transaction to its document rather than to its author; see income audit in hotels: what the day audit checks after night audit.

Where does software help, and where does it stop?#

Software helps with the arithmetic and the memory: computing the band every day, keeping the response log, and routing the alert to the right person. It stops at meaning, which stays with a person.

The arithmetic is the easy part and the part people skip. Recomputing a median and a band for every number, every day, by hand, is exactly the work that gets abandoned in a busy week. The memory matters as much: which rule fired, who answered, what the answer was, and whether the same alert came back. Without that record, tuning is guesswork. Software can also widen coverage, watching numbers nobody has time to chart, such as water per occupied room or postings after checkout.

What it cannot do is say why. A range tells you the number is unusual; the reason sits in a document, a shift handover or a conversation. AI Otel's PMS assistant, built and working ahead of launch, includes an automatic alert when a number moves outside its normal range, with a person confirming anything sensitive. It is working software, not a claim about hotels using it today. The broader question of where AI belongs in hotel accounting is covered in AI in hotel accounting: where it helps the back office and where it must not decide.

Treat any vendor promise of detection without a visible range and a visible response log as a black box you cannot tune, and ask what happens to the alert after it fires.

What to do next#

Pick one number you already record, give it a denominator, and build a range from your own last few months of comparable days. Switch on that single rule, name one owner, and keep a written log of every answer for a month before adding a second. The rest of the discipline, the tuning, the exceptions calendar and the fairness to staff, follows from that first rule working. If you want to see how AI Otel approaches this, you can request a briefing at https://ai-otel.com/contact.