Resource
Five definitions that change every number in your revenue report.
Take one month of bookings. Read it the way most operators read it and you will get three different totals, all of them defensible. Nothing is wrong with the data. Five decisions were never written down.
Every serious disagreement we have seen about a revenue number came down to a definition, not to the data. The property management system was fine. The spreadsheet was fine. Two people were measuring different things and calling them the same name.
Here are the five decisions that cause it, in the order they usually bite. Decide each one once, put the answer in writing, and apply it in one place. Then every report agrees with every other report, and with your accountant.
01Which statuses count as booked
Most property management systems return inquiries in the same collection as confirmed bookings. In Guesty each inquiry carries a complete quoted price, exactly as a booking would.
Sum the collection without filtering and the phantom revenue from quotes that never happened can be larger than the real number. It looks plausible because it is the right order of magnitude. It is simply not revenue.
The fix is a governed list of booked statuses, applied in one place that every downstream report reads from. Not a filter someone remembers to add to each query. When the definition lives in one place it cannot drift between two reports, which is how two people end up in a meeting with different totals for the same month.
Write it down: the exact list of statuses that count as booked, and where that list lives.
02What "closed" actually contains
Status is not a yes or no. Four different things get folded into it:
| Status | What it is | Revenue? |
|---|---|---|
| confirmed | Paid or payment scheduled. Real. | Yes |
| reserved, awaiting payment | Held. Money not yet secured. | Yes, flagged |
| closed | Mixed. Completed stays and owner blocks and comps share it. | Partly |
| inquiry | A quote. Never happened. | No |
Closed is the expensive one. Completed stays with a guest and a payment sit next to owner blocks with zero revenue. The zero-revenue rows contribute nights but no money, so they dilute average daily rate and inflate booking counts without anyone noticing.
The tempting fix is to exclude closed entirely. We tested that on a real portfolio and it broke a reconciliation that otherwise matched the client's own monthly report to the dollar. The right answer is narrower: treat status as a small dimension, keep confirmed separate from held-but-unpaid, and exclude zero-revenue rows from rate metrics while still counting their nights for occupancy. That last choice is genuinely arguable, which is exactly why it should be a visible setting and not a buried assumption.
Write it down: whether owner blocks count toward occupancy, and whether zero-revenue rows are excluded from ADR.
03Which revenue basis you mean
For every reservation there are at least three correct revenue figures:
| Basis | Includes | Who uses it |
|---|---|---|
| Accommodation fare | Rent only | Internal targets, break-even, owner statements |
| Subtotal before tax | Fare plus cleaning, pet and other fees | Most day-to-day reporting |
| Gross, or host payout | The above plus occupancy tax | Published growth, anything compared to an OTA statement |
On a typical professional portfolio the gap between fare and gross is well over twenty per cent. Fee income is real money and it is also not rent. Operators set internal targets on fare. Growth numbers in a press release tend to be gross. Both are right, and a conversation that mixes them goes nowhere.
The failure is concrete. A CEO looks at a tile that says a large number was booked yesterday and cannot tell what it means, because it is gross including held-but-unpaid, and on the fare basis with only confirmed bookings the same day is a fraction of it. One tile, four defensible numbers, none of them labelled.
The rule that fixes it: every money figure carries its basis as part of its identity, not as a caption. Store all three on every row. Let each person choose which they see. Put the basis in the label.
Write it down: the default basis for every report, and the rule for when a different one is shown.
04Booking date or stay date
Two questions that sound like one:
- Booking production. Measured on the date the booking was taken. This is pace. It is what a sales team is judged on.
- Stay-date revenue. Measured on the nights the guest is actually in the property. This is what the business earned.
They need separate models and they must never share a tile. Operators ask for both in the same breath and are then confused by an answer that is correct for the question they did not mean.
It matters most at a boundary. A monthly revenue gate, the kind that switches a commission on or off, read by booking date, by check-in and by check-out, gives three different totals for the same month. We have measured a gate that passed on two of those readings and failed on the third. A person's pay for the month flipped on a definition nobody had written down.
Write it down: the date basis for every gate, target and headline number.
05When revenue is recognised
A five-night stay that starts on the 29th belongs to two months. How much of it belongs to each one is a finance policy, not a technical setting.
Some operators accrue accommodation fare nightly across the stay and recognise fees at check-in. Some recognise everything at check-in. Some at check-out. Your accountant has an opinion and it is the one that counts.
The system's job is to apply your rule, in one place, and to be able to show which rule it applied. It is not to pick one for you.
Write it down: the recognition rule for fare and the rule for fees, separately, and who signed off on it.
What to do with the five answers
Put them in one document. Reconcile one recent month against your own report, on the same definitions, until it matches. If it does not match, one of the five is still wrong, and you have found it before it found you.
Then apply the definitions in one place that every report reads from. Not five places. Not in each dashboard. One.
This is the first week of every engagement we run, before a single detector is switched on. A system that finds revenue opportunities is worthless if the operator cannot trust the baseline it is measuring against. Everything above is what makes the baseline trustworthy.