Net-Payout Modelling in a Spreadsheet: The Six Inputs That Actually Matter

A net-payout model is only ever as good as its weakest input. Most hosts get four of the six right, then wonder why the floor price keeps failing in practice.

Last updated: September 26, 2026

Net-payout modelling means working backwards from the money you need to keep. You list every cost and deduction that sits between a guest's payment and your bank account, then solve for the nightly rate that survives them. It isn't a forecast, and it isn't a pricing strategy. It's a floor — the number below which accepting a booking costs you money.

Key Takeaways

• Six inputs, not four. Nights sold, published rate, channel deductions, per-night levies, turnover costs and fixed costs.
• The two most hosts leave out. Per-stay turnover cost and fixed cost per available night.
• The floor comes before the rate. Solve for the net you need per night, then add costs and deductions back on top.
• Per-stay costs don't scale. A two-night booking carries nearly the same cleaning and laundry as a five-night one.
• Re-derive when terms move. A channel that changes what it charges invalidates every rate you published under the old terms.

What you are actually modelling, and what the model is not for

A net-payout model answers one question: at which nightly rate does this unit stop losing money? Everything in it serves that question. You start from the cash you need to keep each month, divide it by the nights you expect to sell, and then add back the costs and deductions that sit between the guest's payment and your account.

What the model isn't for matters just as much. It won't tell you what the market will pay for your dates. It won't tell you which weekends to hold back for a higher rate. And it isn't a replacement for looking at what your own bookings did last season. A model is a constraint, not a forecast.

Hosts get into trouble when they treat a floor as a target. A floor built properly sits underneath your normal pricing and only shows up at the thin end of a season, when quiet weeks need filling. If every night is priced at the floor, the model has stopped doing its job — it's now setting your rate rather than guarding it.

The six inputs, and the two most hosts leave out

Six numbers go in. Nights sold is the count you expect to actually sell, not the count the calendar offers. Published rate is what the guest sees before anything is deducted. Channel deductions are whatever the platform takes under its current terms, which differ by platform and change over time. Per-night statutory levies are the local charges that attach to each occupied night, and they vary by city.

The last two are the ones that go missing. Turnover cost — cleaning, laundry, restocking, the consumables a guest never notices — is a cost per stay, not a cost per night. A two-night booking carries almost the same turnover as a five-night booking, so the effective cost of each night rises sharply as the stay shortens. A model that spreads turnover evenly across nights understates exactly the bookings you take most often.

Fixed cost is the second omission. Rent or mortgage, insurance, utilities that don't follow occupancy, and the software you run the business on all keep running through an empty month. Add them up, spread the total across the nights you expect to sell, and you get a fixed cost per available night. Leave that line out and your floor sits too low by precisely that amount. If you want a real number for the software part of it, LOCALSBNB's own plans run at $4.5 per room per month on annual billing and $7 month-to-month, which is enough to see whether the line matters at your unit count.

Building a floor: from the net you need back to a rate you can publish

Start with the net. Decide what this unit has to put in your pocket each month, divide by the nights you expect to sell, and you have the net you need per night. That single figure is what the whole model exists to protect.

Then add back, in order. Add turnover cost divided by the length of a typical stay. Add the per-night levies. Add the fixed cost per available night. What you have now is the amount that has to survive the platform's cut before it reaches you.

Only then do you gross up for channel deductions, and this is where the arithmetic turns local. Each channel takes what its current terms say it takes, and those terms differ by platform, by market and over time. Two identical bookings on two channels can leave you with different amounts, so build one version of the model per channel rather than one blended figure across all of them. A blended number is comfortable to read and useless for deciding where to push a rate.

That's also where a shared calendar earns its place. When you push a floor out, you want to see what each channel is actually quoting as its source rate, and whether that rate is live or paused. LOCALSBNB shows the source price and the source status for every connected channel on the same grid, so the rate you modelled and the rate you published stay comparable. You can see the same layout at localsbnb.com before you commit a season's worth of rates to it.

Re-deriving the model the first time a channel changes what it charges

Every channel reserves the right to change its terms, and most do it. Sometimes it's a restructure of what gets charged. Sometimes it's a change to what a fee covers. Your model has one line for deductions, and that line carries a date. Once the date passes, the line is a guess dressed up as a number.

Re-deriving isn't hard, but it has to be deliberate. Take the new terms, change that one input, and watch what happens to the floor. If the floor moves by more than a rounding error, the rates you published under the old terms were quietly wrong. The longer those rates stay live, the more nights you sell at a price the model no longer supports.

Then decide what to do about the gap. You can raise the floor, shorten the minimum stay so fewer short bookings land, or accept a thinner net for one season while you re-cut the rates. What you shouldn't do is leave the sheet untouched and assume the difference is small. A deduction change compounds across every night you sell for as long as the old rate stays up.

One habit makes the next revision cheap. Keep the six inputs on a single sheet, with the source and the date written beside each one. When a channel moves, you change one cell, read the new floor off the sheet, and know within a minute which of your published rates are now under it.

FAQ

Do I need a separate model for every channel?

Yes, or one model with a row per channel. Deductions differ, and a single blended figure hides which channel is actually earning its place. Run four channels and you have four floors, even if three of them land close together.

What about nights I block for myself?

Blocked nights still carry fixed cost. If you hold back twenty nights a year, the fixed cost per available night goes up for every night that's left. Build the model on available nights rather than sold nights, or the floor comes out too low.

How often should I re-derive it?

Whenever a channel changes its terms, and once a season regardless. Rates drift, costs drift, and a model you last touched a year ago describes a business you no longer run.

A floor stays useful only while it's current and comparable. Keep the six inputs dated. Re-run the arithmetic the moment a channel moves. And when a rate goes live, check that it matches the floor you modelled rather than the one you remember. Hosts who do that stop finding a broken model at the end of a season; the calendar at localsbnb.com is where that check starts.

---

This article is general guidance for hosts and isn't financial, tax or platform policy advice; channel terms and local charges vary, and the current terms of each platform prevail.