RevPAB Explained: The Coliving Yield Metric

Occupancy tells you how full you are. Achieved rate tells you how much you charge. Neither tells you how much your beds are actually earning, because you can lift one by sacrificing the other. RevPAB is the single number that holds both together, and for coliving it is the yield metric that belongs at the top of the board pack.

This post covers what RevPAB means, the formula and why it is exactly equal to occupancy times rate, a worked example, how it differs from the per-unit sibling RevPAU, the mistakes that quietly inflate it, and how to set a target you can defend without quoting an industry average nobody can verify.

What RevPAB means

RevPAB stands for Revenue Per Available Bed. It is the revenue a bed generates on average across every night it was available to let, whether or not it was actually let. The word available is the important one. The denominator is not the beds you filled, it is the beds you could have filled.

That is what makes it a yield metric rather than a volume metric. A bed sitting empty does not shrink the denominator, so RevPAB is penalised for void in exactly the way your bank balance is. It is the coliving analogue of RevPAR in hotels and of the wider Revenue Per Available Unit family used across build to rent and student housing.

The formula

Start with the definition, then the identity that makes it useful.

Available bed-nights = beds in service x nights in period
RevPAB               = total bed revenue in period / available bed-nights

RevPAB is usually quoted as a per-night figure. Multiply by the nights in the period to get a per-bed-per-month or per-bed-per-year number for budgeting.

The identity that makes RevPAB worth calculating is that it decomposes cleanly into your two operating levers:

RevPAB = Occupancy x ADR

  where  Occupancy = occupied bed-nights / available bed-nights
         ADR       = total bed revenue / occupied bed-nights
                     (average achieved rate per occupied bed-night)

The algebra is trivial but the point is not. Revenue equals occupied bed-nights times ADR. Divide both sides by available bed-nights and the occupied bed-nights term splits into occupancy times ADR. So RevPAB is literally occupancy multiplied by achieved rate. Any change in RevPAB traces back to one lever, the other, or both, and you can always say which.

Worked example

Suppose a 120-bed coliving portfolio, all beds in service, over a 30-day month, with these illustrative inputs:

• Occupancy: 92%
• ADR (achieved rate per occupied bed-night): an illustrative £32

Available bed-nights = 120 x 30            = 3,600
Occupied bed-nights  = 3,600 x 0.92         = 3,312
Bed revenue          = 3,312 x £32          = £105,984
RevPAB (per night)   = 105,984 / 3,600      = £29.44
Check: Occupancy x ADR = 0.92 x 32          = £29.44
RevPAB per bed / month = 29.44 x 30          = £883

The £29.44 is the number that matters. It already carries the cost of the 8% void: the ADR was £32, but each available bed only returned £29.44 a night once the empty nights were spread across the whole inventory.

Why RevPAB beats occupancy or rate on their own

The reason to run RevPAB rather than watch occupancy and rate separately is that the two trade off against each other, and a single metric forces an honest comparison. Take two illustrative properties over the same month:

Property A looks better on the metric most operators report to investors, occupancy, and it is almost full. Property B earns more per available bed. If you only watch occupancy you will congratulate the wrong building and, worse, you will push A's manager to discount even further to protect a number that is already costing you yield. RevPAB settles the argument because it is denominated in money per bed, which is the only thing the P and L recognises.

This is the same logic behind good bed-level pricing: the goal is not maximum occupancy or maximum rate, it is maximum RevPAB. See the companion post on bed-level pricing strategies for the pricing side of the same equation.

RevPAB vs RevPAU: which denominator

RevPAB has a sibling, RevPAU, Revenue Per Available Unit. RevPAU divides revenue by available units or rooms rather than beds. The two are identical for a portfolio of self-contained one-bed units, and they diverge the moment you sell a building by the bed.

The rule is simple: measure on the unit you actually sell and can let independently. In coliving and most HMOs you sign an agreement per bed or per room, so the bed is the lettable unit and RevPAB is the right denominator. In build to rent, where you let a whole apartment on one tenancy, the apartment is the lettable unit and RevPAU is the natural metric. A cluster flat in student housing can go either way depending on whether you let the cluster or the rooms.

If you report RevPAU across a bed-let portfolio you will hide exactly the void that RevPAB is designed to catch, because a six-bed house with one empty bed still counts as one fully available, fully let unit. For the build to rent version of this metric and how the maths carries across, see RevPAU explained for BTR operators.

Gross, net, and total RevPAB

Decide which revenue sits in the numerator before you compare anything, because three different RevPABs are all legitimate and they are not interchangeable:

• Rent RevPAB: base rent only. The cleanest measure of core letting yield and the one to trend over time.
• Total RevPAB: rent plus recurring ancillary revenue that scales with occupied beds, such as bills packages, parking or amenity fees. Useful for revenue planning, but it flatters comparisons against operators who unbundle bills.
• Net RevPAB: after directly attributable costs such as payment processing or platform commission. Closer to contribution, and the right basis when you compare a direct-let channel against an intermediated one.

None of these is more correct than the others. What is incorrect is comparing your total RevPAB against someone else's rent RevPAB and concluding you are ahead. Label the numerator every time.

Four ways RevPAB gets quietly inflated

1. Dropping out-of-service beds from the denominator. A bed under refurbishment is a capital decision, and removing it from available bed-nights is defensible for a lettings metric. But do it silently and RevPAB rises for free, because you shrank the denominator without earning anything. Report the count of out-of-service beds alongside RevPAB so the two move visibly together.
2. Using snapshot occupancy. If occupancy is read on the first of the month, mid-month voids vanish and the occupancy term in RevPAB is overstated. Always drive RevPAB from bed-night occupancy, summed across actual paid nights.
3. Averaging property-level RevPABs. RevPAB is a ratio, so aggregate the numerator and denominator across the portfolio and divide once. Averaging each property's RevPAB weights a four-bed house the same as a forty-bed block and gives a number that matches no bank statement.
4. Counting reserved-but-not-started beds as occupied. A signed bed with a move-in three weeks out earns nothing tonight. It belongs in available bed-nights and out of occupied bed-nights until the paid term begins.

Setting a RevPAB target you can defend

Do not benchmark RevPAB against a portfolio you do not control, because the number is not comparable across operators without normalising for stay length, city, product tier, whether bills are bundled, and how out-of-service beds are treated. Any single industry figure that ignores those is noise.

Benchmark against your own decomposition instead. Because RevPAB is occupancy times ADR, a RevPAB target is really two targets, and separating them tells you which team owns the gap:

Target RevPAB = Target occupancy x Target ADR

Gap analysis:
  RevPAB shortfall from occupancy = (target occ - actual occ) x actual ADR
  RevPAB shortfall from rate      = (target ADR - actual ADR) x target occ

Now the board conversation is concrete. If most of the shortfall sits in the occupancy term, it is a void and lettings problem. If it sits in the rate term, it is a pricing and product problem. Set the movement, for example lift RevPAB by 4% by recovering two points of occupancy without conceding rate, and you have a target that is attributable, testable, and actually true of your portfolio.

Where this connects

RevPAB is the headline that void feeds into: every void night pulls the occupancy term down, so the natural next read is how to calculate and reduce void period cost. The rate term is set by bed-level pricing strategies, and RevPAB sits inside the broader set of per-bed reporting KPIs that operators track. If you are weighing tools to run these numbers, the pricing model itself matters too: see per-bed vs per-unit PMS pricing. Definitions for RevPAB, RevPAU and available bed-nights live in the shared living glossary.

Computing RevPAB by hand once a quarter is possible. Computing it per bed, per building and per channel every week, with the occupancy and rate terms split out, is what a purpose-built system is for. JumboTiger surfaces RevPAB and its decomposition in the revenue management and reporting and analytics modules, built for coliving operators who sell by the bed.