Net-First Pricing: Working Backwards From What You Keep
Pricing and Revenue

Net-First Pricing: Working Backwards From What You Keep

Localsbnb 內容團隊2026年10月28日閱讀約 7 分鐘

Start from the amount a unit has to bank, add back what the channel deducts, and the listed price stops being a guess. The order of the additions is where most hosts go wrong, because each charge applies to its own base rather than to the running total.

Screenshot of the LOCALSBNB rate plans page showing nightly rates, cancellation policy and channel columns, used to illustrate where a listed price is maintained before channel deductions
The rate plan page is where the output lands, not where the calculation starts.

Start from the amount you need to bank, add back what the channel deducts, and the listed price stops being a guess. The order of the additions is what most hosts get wrong.

Last updated: October 27, 2026

Pricing forwards means guessing at three things at once: what the channel takes, what it takes it from, and what never belonged to you. Pricing from the net means knowing one thing instead — what the unit has to bank — and treating everything above it as a sequence you can write down and reuse. The listing page ends up with a number either way. Only one of the two routes can explain it.

Key Takeaways

  • Anchor on the net, not the rate. What the unit has to bank is a number you know. The listed price is what you solve for.
  • Each charge has its own base. Adding every deduction to a running total is the single most common error, and it gets worse as the price rises.
  • Pass-throughs go in and come straight back out. Guest tax collected on someone else's behalf passes through the statement; it isn't part of what you're building.
  • Currency belongs at the end. Conversion applies to a transfer, not to a rate, so it's the last addition rather than the first.
  • Share the order, not the numbers. One sequence, run per unit. A portfolio that averages its deductions hides the unit that nets worst.

Start at the payout, not the price

Name the figure the unit has to produce. Not profit, and not the mortgage — the contribution the stay has to leave behind once the stay's own costs are paid: the clean, the linen, the utilities that run because someone was there.

Write that number down per unit, because it varies inside the same building. A studio with a short minimum stay turns over more often than a two-bedroom that takes week-long bookings, and the turnover cost per night sold differs between them even when the nightly rate is identical.

Then write down what the stay costs to deliver, kept separate. Two figures, kept apart, are what make the rest of this method work: one is the amount that has to land, the other is what the stay consumes on the way. Merge them and you lose the ability to tell a pricing problem from a cost problem.

What you haven't written down yet is the listed price, and that's the point. It's an output. Once the two inputs exist, the listed price is whatever survives the deductions between the guest and your bank — and it's different on every channel, which is the part a single markup can't handle.

Adding back in the right order

Read one statement from top to bottom and write the sequence down. That sequence is your build-up order, and it's fixed until the channel changes its terms.

Three rules govern it. First, add each charge to the base it's actually calculated on. A charge the channel applies to the room rate doesn't get added to a total that already includes the cleaning fee, and a charge applied to the collected amount doesn't get added to the rate you typed. Same charge, two bases, two different answers.

Second, add pass-throughs and take them out again. Where a guest tax is collected through the platform and remitted on your behalf, it enters the chain and leaves it. If you build it into the price as though it were yours, you'll pay it twice: once to the authority and once to your own margin.

Third, currency last. Conversion happens when money moves, not when a rate is set, so the rate you build has to be converted at the point of transfer. Put it at the front and every subsequent addition inherits a rate that may not exist by payout.

The point of those three rules is to kill the one-markup habit: adding a single uplift to the net target to cover "everything the channel takes". It over-covers some charges and under-covers others, and because the shortfall lands on whichever charge has the widest base, the gap widens as the price rises. You end up repricing every few months and never learning which charge you were short on.

Here's where the per-channel part becomes concrete. localsbnb.com shows each connected channel's own rate and its status next to yours, so a build-up that produces a different listed price per channel is visible on one screen instead of several. The sequence is shared; the output isn't, and it shouldn't be.

Where the arithmetic breaks

Four places where it breaks, and each one has a test.

The base is invisible. The channel applies a charge to something you can't see from the listing: a promotion applied before the fee, a cleaning fee included in one rate plan and excluded in another. Test it on a single completed booking — take the three figures from the statement and see which base reproduces the charge. Whichever one does is your base, whatever the label says.

The guest price isn't the charge base. Where a tax is collected on top and remitted, the amount the guest pays is larger than the amount the channel charges its fee on. Build from the guest price and your listed price comes out high; build from the charge base and the tax gets added once, at the point where it applies.

A discount enters before the fee. A weekly rate or a last-minute reduction changes what's collected, and the fee follows it down. So the add-back has to be built on the collected amount at the discount you actually run, not on the rate on the calendar. This is why a discount that looks affordable on the pricing screen can still land under the floor.

The unit mix changes. Same method, different inputs — and this is where a portfolio goes wrong. Averaging the deduction across units produces a number that's right for none of them, and it always flatters the unit that nets worst. Recompute per unit; the arithmetic takes minutes once the sequence is written down.

Keeping the floor visible

The floor isn't a pricing decision, it's a constraint, and constraints only work when they're in sight. Put it where you set rates, on the same screen as the rate field, so you can't set a price without seeing it.

Renew it when a cost moves — the cleaner's rate, utilities, the linen replacement cycle — rather than when occupancy dips. Occupancy is a demand signal. Reacting to it by moving the floor turns the floor into a target, and a floor that follows demand isn't a floor.

Keep the performance numbers separate. Occupancy, ADR and RevPAR tell you how the month went; LOCALSBNB reports them per unit on one dashboard. None of them tells you whether the month cleared the floor, and a healthy ADR on a unit with a thin net is a worse result than a modest ADR that cleared it comfortably. Read the two together, in that order: floor first, performance second.

Card: the four additions in build-up order, each applied to its own base rather than to a running total
Net, then charges on their own bases, then pass-through tax, then currency: four steps, fixed order.
Card: comparison of four places the build-up breaks — invisible base, guest price versus charge base, discount before fee, and averaged unit mix
Four failure points, four tests you can run on one completed booking.
LOCALSBNB — start free

FAQ

Is net-first pricing the same as cost-plus?

No, and the difference is the anchor. Cost-plus starts at what the stay costs and adds a margin, then discovers what the channel takes. Net-first starts at what has to land after everything, so the deductions are inside the calculation from the beginning rather than subtracted at the end.

What if I can't tell what base a channel uses?

Reproduce it from one statement. Three figures from a single completed booking are usually enough to identify the base, because only one base will produce the charge you were actually given. Write it down with the date, and re-test when the channel's terms change.

Does every unit need its own price?

Every unit needs its own inputs, not its own method. The sequence of additions is the same across a portfolio; the target net, the cost per stay and the discount you run aren't. Sharing the order is what makes the method fast. Sharing the numbers is what makes it wrong.

Net-first pricing is slower once and faster every month after, because the number you solve for stops moving while the deductions keep changing around it. localsbnb.com puts each connected channel's rate and status beside your calendar, so you can see where a listed price has drifted away from the sequence that built it.


This article is general guidance for hosts and isn't legal, tax or insurance advice, and it isn't financial advice. Channel charges, tax treatment and currency handling differ by platform and jurisdiction and change over time. Confirm the current terms of each channel you use and the current rules with the competent authority before you set a price.

審核

Localsbnb 內容團隊