ADR times 365 times occupancy is not an income model. Here are the six line items that turn a projected winner into a property you fund out of pocket four months a year.
Last revised August 8, 2026
Every short-term rental deal I have watched go bad was killed by the same thing: a revenue estimate that was technically defensible and practically fiction. The buyer took a nightly rate off a comp, multiplied by 365, applied a haircut they felt good about, and called it income. Twelve months later the property was cash-flow negative and nobody could point to the line item that lied.
The lie is almost never the nightly rate. It is the occupancy assumption and the expense categories that a standard rental spreadsheet does not have rows for.
The math that kills deals
Most calculators model STR income as ADR × 365 × occupancy. That formula is not wrong, it is just far too coarse to underwrite with. It hides three problems:
Occupancy is not a single number. Short-term rental demand is seasonal, and in most markets the spread between peak and trough month is not 10 or 20 percent, it is a multiple. A property at 78% in July and 31% in February does not behave like a property at 55% year-round, even though the annual average is identical. The 55% version pays its mortgage every month. The real one has four months where you fund the shortfall out of pocket.
Average Daily Rate moves with occupancy. You do not get peak ADR at trough occupancy. Discounting to fill February nights is exactly what everyone else in your market is also doing, so your worst months are hit twice: fewer nights and lower rates on the nights you do book.
Gross booking value is not revenue. Platform fees, cleaning pass-throughs, and lodging taxes all sit between what the guest pays and what lands in your account. If your spreadsheet starts from the number on the listing, you are already over-counting.
The fix is not a better guess. It is a monthly model instead of an annual one — twelve rows, each with its own ADR and its own occupancy — and then a bottom line you read as a minimum month, not an average.
The six numbers people leave out
When I rebuilt our short-term rental income analyzer I forced every one of these into its own visible row, because burying them in a single "expenses" percentage is how a bad deal passes review:
- Real day counts. February is not 30 days. Using 30 across the board overstates annual nights by five and understates the seasonal swing.
- Cleaning as a per-turn cost, not a monthly one. Cleaning scales with bookings, not with time. A high-occupancy month with short stays can cost more to clean than a slow month with two week-long guests.
- Lodging and occupancy taxes. These are local, they are frequently in addition to state sales tax, and they are not optional. Check your municipality directly; the rate is often set at the city or county level.
- Utilities you do not pay on a long-term rental. In an STR the operator pays electricity, water, gas, internet, and streaming. On a long-term lease most of that is the tenant's. This single category is why an STR pro forma built from an LTR template is always too optimistic.
- Furnishing amortization and replacement. The initial furnish is capital, but linens, cookware, and a mattress that gets 200 nights a year are recurring. Spreading a realistic replacement reserve across the year is more honest than pretending year one is representative.
- *Vacancy that is not booked or blocked.* Owner stays, maintenance days, and turn buffers are unavailable nights that no occupancy number from a comp tool will tell you about.
Where to get inputs you can defend
Guessing is the failure mode, so anchor each input to a source you can cite back to yourself in six months:
- Demand and ADR comps: AirDNA is the standard paid source for market-level ADR and occupancy. Whatever you use, pull monthly figures, not the annual summary — the annual number is the one that hides the seasonality.
- Tax treatment: IRS Publication 527 governs residential rental property, including the rules for properties with significant personal use. The 14-day thresholds materially change your after-tax outcome and belong in the model, not in a note.
- Financing assumptions: Freddie Mac's Primary Mortgage Market Survey is the primary source for the weekly 30-year average. Date-stamp whatever you use — it matters when you revisit an underwrite months later and want to know what you assumed.
- Return metric definitions: if you are comparing deals on cash-on-cash, use a consistent definition — Investopedia's is fine as a reference point. The metric is only useful if every deal in your pipeline computes it the same way.
- Local rules: many cities cap or license STRs, and a permit denial is a total loss of the thesis. Check the municipal code before the spreadsheet, not after.
The test a good calculator has to pass
Here is the check I run on any STR model, mine included: set occupancy to the worst month you can find in the comp data and see whether the property still covers debt service. If it does, you have a business. If it only works at the annual average, you have a seasonal bet that needs a cash reserve sized to the trough — and the model should tell you how big that reserve is.
The second check: change one input and see how many outputs move. If your cleaning cost is a flat monthly number, raising occupancy will make the property look more profitable per night with no added cost. That is a modeling bug, and it is extremely common in free templates.
A spreadsheet is not a prediction. It is an argument about a property, and its value is entirely in how easy it is to attack. Build it so the numbers you are least sure about are the ones sitting in their own labeled cells, where a skeptic — ideally you, in a worse mood — can push on them one at a time.