RevPAU is the yield metric that tells you what occupancy and rent, looked at separately, cannot. This post covers what it means, the formula, worked examples you can copy into a spreadsheet, and where it helps and where it quietly misleads. All figures below are illustrative inputs, labelled as such, not observed benchmarks. If you take one thing away, let it be this: a portfolio can raise rents and lose revenue at the same time, and RevPAU is the number that catches it.
What RevPAU measures
RevPAU stands for Revenue Per Available Unit. It is the build-to-rent and flex-living cousin of RevPAR (revenue per available room), the metric hotels have used for decades. RevPAU answers one question that occupancy and rent cannot answer on their own: how much revenue is each unit in your portfolio actually generating, whether or not it happens to be let tonight?
That word "available" is the important one. RevPAU spreads revenue across every unit you could have let, not just the ones you did. A unit sitting empty drags RevPAU down, exactly as it should, because an empty unit is a real cost to the portfolio. That is what makes RevPAU a truer yield signal than headline rent.
The formula
At its simplest:
RevPAU = Total rental revenue in a period / Available unit-nights in that period
where Available unit-nights = units in service x nights in the periodRevPAU is usually expressed per available unit-night, or scaled up to per available unit per month or per year. The other identity, and the one that makes it click, is:
RevPAU = Occupancy rate x ADR
where Occupancy = Occupied unit-nights / Available unit-nights
ADR = Total revenue / Occupied unit-nights (average rate per occupied unit-night)Both give the same answer. The first is top-down from revenue, the second is bottom-up from your two operating levers. Knowing both is useful, because the second tells you why RevPAU moved.
Worked example
Suppose a 300-unit build-to-rent scheme over a 30-day month (illustrative inputs throughout):
Units in service = 300
Available unit-nights = 300 x 30 = 9,000
Occupancy = 92%
Occupied unit-nights = 0.92 x 9,000 = 8,280
ADR (rate per occupied unit-night) = £55
Total revenue = 8,280 x £55 = £455,400
RevPAU per available unit-night = 455,400 / 9,000 = £50.60
check: 0.92 x 55 = £50.60
RevPAU per available unit, monthly = £50.60 x 30 = £1,518
check: 455,400 / 300 = £1,518So each unit in the scheme generated £1,518 of revenue for the month on average, against £1,650 (£55 x 30) if every unit had been full every night. The £132 gap per unit is the cost of that 8% vacancy, made visible in money.
Why one number beats two
Operators routinely report occupancy and average rent as separate headlines, and the two can move in opposite directions. Push rent hard and occupancy softens. Chase occupancy with concessions and rate falls. Looking at either number alone, you cannot tell whether a change helped or hurt the portfolio. RevPAU collapses both into the single figure that matters, revenue per available unit, so a pricing or leasing decision can be judged on whether it raised RevPAU, not on whether it moved one lever in isolation.
This is the same logic behind the metrics in flex-living revenue formulas: the yield number has to combine rate and utilisation, or it misleads.
A worked comparison
Two schemes, same month, illustrative figures:
| Scheme | Occupancy | ADR | RevPAU per available unit-night |
|---|---|---|---|
| Parkside | 96% | £48 | £46.08 |
| Canalworks | 88% | £54 | £47.52 |
Parkside is fuller. Canalworks charges more. On occupancy alone Parkside wins, on rate alone Canalworks wins, but Canalworks generates more revenue per available unit. Neither headline told you that. RevPAU did.
Getting the denominator right
RevPAU is only honest if "available units" is defined with discipline. The traps mirror those in occupancy reporting:
- Out-of-service units. A unit pulled for major refurbishment is arguably not available and can be excluded from the denominator, but doing so flatters RevPAU and can hide a unit that has been "temporarily" closed for months. Best practice is to report RevPAU on in-service units, and separately track the share of the portfolio out of service, so the two together tell the whole story.
- Snapshot vs unit-nights. Calculate on unit-nights across the period, not a point-in-time occupancy, or every mid-month void vanishes from the figure.
- What counts as revenue. Decide whether RevPAU includes only accommodation revenue or also ancillary income like parking and amenity fees, and whether it is gross or net of concessions and free-week incentives. Net effective revenue is usually the more honest input. Whatever you choose, apply it consistently, because RevPAU is only comparable against itself.
The per-unit discipline here is identical to the per-bed logic in per-bed reporting KPIs: aggregate revenue and unit-nights, then divide. Never average unit-level rates.
Net effective, not headline
The concession question deserves its own paragraph because it is where RevPAU is most often quietly inflated. A unit advertised at £1,650 a month but let with two months free on a twelve-month term does not earn £1,650. It earns £1,650 times ten twelfths, or £1,375 in net effective terms, before you even account for any void. If your RevPAU is built on headline rents rather than net effective revenue, it will read higher than the cash the portfolio actually collects, and it will flatter exactly the schemes that are buying occupancy with the heaviest incentives. During a soft leasing market, that gap between headline and net effective RevPAU is one of the most useful things a portfolio can watch, because it shows the true cost of holding occupancy up.
RevPAU and its per-bed cousin
RevPAU is a per-unit metric, which suits build-to-rent because the unit of letting is a whole home. In shared living, where a single home holds several income-producing beds, the equivalent yield metric is calculated per bed rather than per unit, sometimes written RevPAB, revenue per available bed. The arithmetic is identical, only the denominator changes from available unit-nights to available bed-nights. If you run a mixed portfolio spanning whole-unit and shared inventory, decide up front which denominator each scheme reports on, and never blend the two into one headline. The distinction, and why per-bed inventory matters for shared models, runs through per-bed reporting KPIs and the operating-model differences in BTR vs PBSA vs coliving.
RevPAU across the flex-to-long spectrum
RevPAU earns its keep most where stays are shorter and rate moves more often: serviced apartments, aparthotels, and the flex end of coliving, where it functions much as RevPAR does in hotels. In long-lease build-to-rent, where rent is fixed for a year and occupancy is high and stable, RevPAU moves slowly, but it remains the cleanest way to compare schemes, unit types and time periods on a like-for-like basis, because it normalises for size and for vacancy at once. For operators running mixed models, RevPAU is one of the few metrics that speaks across the whole book.
What RevPAU does not tell you
RevPAU is a revenue metric, not a profit metric. It says nothing about the cost of generating that revenue. Two schemes with identical RevPAU can have very different net operating income if one carries far higher running costs. Hotel operators extend RevPAR toward profit with measures like GOPPAR (gross operating profit per available room), and the same idea applies here, but that is a step beyond RevPAU itself. Treat RevPAU as the top-line yield signal, then layer cost on to reach profitability. It is also silent on retention and rent-growth durability, which is why it sits alongside, not instead of, the renewal metrics in BTR resident retention.
How to use it
- Track it over time per scheme, to see whether pricing and leasing decisions are compounding or cancelling out.
- Compare unit types on RevPAU rather than rent, so a smaller unit that stays fuller gets fair credit.
- Set it as a target that forces the trade-off, since a team told to lift RevPAU cannot simply slash rate for occupancy, nor hold out for rate at the cost of empty units.
Where this connects
RevPAU is one of the core yield metrics build-to-rent operators report to investors, alongside occupancy, net effective rent and retention. For the tooling that calculates it from live lease and occupancy data, see our BTR software use case, the best BTR software roundup and the BTR software buyer's guide. For how the metric set changes across operating models, see BTR vs PBSA vs coliving.
A platform like JumboTiger computes RevPAU from unit-night occupancy and net effective revenue, so the yield figure you report is derived from the same source data as your rent roll.
