How do Occupancy Metrics work with Split Inventory

Split Inventory allows properties to sell a physical space in multiple ways, maximizing revenue and occupancy. To understand occupancy calculations, it's crucial to differentiate between:

• Physical rooms: These are the actual "keys" or physical spaces available at your property. They always have associated capacity and are the only room types that contribute to occupancy calculations.
• Virtual rooms: These are not physical "keys" and do not have capacity. They represent flexible ways to sell a physical space (e.g., combining two standard rooms into a suite).

The image shows the "Link Accommodations" for Split Inventory setup, highlighting primary and secondary accommodation types:

The fundamental occupancy definition is: Total Rooms Sold ÷ Total Rooms Available.

• When using Split Inventory, the system correctly reports occupancy based on physical rooms only.
• Occupancy % = ([Physical Rooms Sold]) / ([Physical Rooms Available]) * 100.
• Rooms available for benchmarking purposes do not remove blocked and Out of Service (OOS) rooms; at Cloudbeds, this is currently the same as the total capacity of physical rooms.

As an example, here's a report showing Physical and Virtual rooms, with Physical rooms having capacity and rooms sold, and Virtual rooms having no capacity or rooms sold:

For Split Inventory properties, accurate reporting on revenue metrics like ADR and RevPar is possible only at the stay date level.

• ADR (Average Daily Rate) = Total Room Revenue ÷ Total Physical Rooms Sold.
  • Rooms sold are physical rooms only, accounting for split inventory.
  • Total Room Revenue includes room rate, manual room revenue, and no-show fees, but excludes inclusive or exclusive taxes and fees, and cancellation fees.
• RevPar (Revenue Per Available Room) = Total Room Revenue ÷ Total Physical Rooms Available.
  • Rooms available are physical rooms only (split inventory) and include blocked and OOS rooms. At Cloudbeds, this typically equals total physical inventory.
  • Total Room Revenue definition is the same as for ADR.

If you have Cloudbeds Insights (report builder) enabled, you can add the “Accommodation Kind,” CDF to your Occupancy dataset reports. This allows you to easily identify whether a room is virtual or physical directly within your reports.

In Cloudbeds, Split Inventory configurations can be grouped as either Tiered or Non-Tiered, depending on how virtual and physical rooms are linked. This structure directly affects how occupancy and revenue are tracked.

• Tiered Configurations: These involve multiple layers of links between accommodations. A typical setup connects a virtual room to another virtual room, which then links to one or more physical rooms. For example: Virtual → Virtual → Physical.

This type of setup allows properties to create more complex offerings, such as combining an existing virtual suite with multiple physical rooms to sell an entire floor.

• Non-Tiered Configurations: These involve a direct connection from a virtual room to physical or other virtual rooms, without intermediate layers. Examples include:
  • Virtual → Physical: Used when properties want to sell a group of rooms together (like a duplex or an entire floor) but also keep the option to sell individual rooms.
  • Virtual → Virtual: Used for selling non-room resources like parking, meeting rooms, or restaurant tables. These setups do not affect occupancy metrics.

Allows grouping of an already combined virtual room with an additional physical room — for example, to sell an entire floor that includes a suite and another standalone room.

Below it's an example of a property that has 16 physical rooms and 11 virtual rooms. Its total Capacity is 16.

This screenshot shows the VIR(1) unit linked directly to VR(1), PHY(1), and PHY(2) units, where VR(1) is already a virtual suite:

This is how it would look on a report:

How to read the report?

1. 1. There’s a reservation for the VIR(1) room with a stay date of 2025-05-21.
   2. Physical 1 has capacity, while the Virtual 1 and Virtual 2 do not have capacity.
   3. VIR(1) is not marked as sold but has the revenue associated with the booking.
   4. VR(1) (aka the Virtual suite) is not marked as sold and does not have any revenue associated (the revenue is associated with the actual booked virtual room).
   5. The linked physical rooms PHY(1) and PHY(2) are marked as sold but do not have revenue associated (the revenue is associated with the actual booked virtual room).
   6. Occupancy is calculated based on the physical units sold — in this case, 2/16.

This configuration involves a virtual room connected to a physical room, which itself is linked to another physical room. It allows more complex setups such as modeling a room suite with a secondary room that may serve as an extension or optional addition.

Below is an example of a property with 4 total rooms (2 physical rooms in each chain). Its total Capacity is 4.

This screenshot shows the VT(1) unit linked to PHT(1) and PHT(2), and the VT(2) unit linked to PT2(1) and PT2(2):

This is how it would look on a report:

How to read the report?

1. 1. There’s a reservation for the VT(1) room with a stay date of 2025-06-04.
   2. Physical Test and Physical Test 2 have capacity, while Virtual Test does not have capacity.
   3. VT(1) is not marked as sold but has the revenue associated with the booking.
   4. PT2(1) and PT2(2) are not marked as sold and do not have revenue associated (the revenue is associated with the actual booked virtual room).
   5. PHT(1) and PHT(2) are marked as sold but do not have revenue associated (same note as above).
   6. Occupancy is calculated based on the sold physical rooms — in this case, 2/4 = 50%.

This configuration lets you sell a space in three ways: as a whole place (top-level virtual), as a combined floor (intermediate virtual), or as the individual physical rooms.

Below is an example of a property that has 21 physical rooms and 12 virtual rooms. Its total Capacity is 21.

This screenshot shows the top-level virtual unit VR(1) linked to two virtual units (VT(1) and VT(2)). One of those virtuals — VT(1) — is further linked to two physical units: PHT(1) and PHT(2).

This is how it would look on a report:

How to read the report?

1. There’s a reservation for VR(1) with a stay date of 2025-06-01.
2. Virtual and Virtual Test (the two virtual room types) do not have capacity; the physical room type Physical Test does.
3. VR(1) is not marked as sold but holds the full revenue for the booking.
4. The intermediate virtuals VT(1) and VT(2) are not marked as sold and have no revenue associated.
5. The linked physical units PHT(1) and PHT(2) are marked as sold but show no revenue (revenue stays with the actually booked virtual room).
6. Occupancy is calculated from physical rooms sold — in this case, 2/21.

This configuration is used when a virtual accommodation is linked to another virtual room, typically to represent non-room resources or layered non-physical offerings.

These setups are useful when no physical units are involved — for example, representing access to a shared amenity, workspace, or bundled service (such as parking, meeting rooms, or tables in a restaurant) when you don't want to affect occupancy.

Below it's an example of a property that has 16 physical rooms and 11 virtual rooms. Its total Capacity is 16.

This screenshot shows the VR3(1) linked to another virtual room VR4(1), with no physical rooms in the chain.

This is how it would look on a report:

How to read the report?

1. 1. There is a reservation for the Virtual 3 room with a stay date of 2025-05-23.
   2. No physical units are linked, so Virtual 3 is shown with revenue but zero capacity or rooms sold.
   3. Virtual 4 (linked virtual) does not contribute to revenue or occupancy and is not marked as sold.
   4. Since no physical rooms are sold, occupancy remains 0% — even though revenue is generated.

Used when combining two or more physical rooms into a single virtual accommodation (e.g., you have 2 physical deluxe rooms you want to be able to sell as a duplex), while allowing those rooms to still be sold individually. 

Below it's an example of a property that has 22 physical rooms and 12 virtual rooms. Its total Capacity is 22.

This screenshot shows the VR2(1) unit linked directly to PH2(2) and PH2(1) units: 

This is how it would look on a report:

How to read the report?

1. 1. There's a reservation for the Virtual 2 room with a stay date of 2025-06-02
   2. Physical 2 has capacity, while the Virtual 2 does not have capacity.
      
   3. Virtual 2 is not marked as sold but has the revenue associated with the booking.
   4. The Physical 2 room type (PH2(2) and PH2(1) units) are marked as sold but do not have revenue associated (the revenue is associated with the actual booked virtual room).
   5. Occupancy is calculated based on the physical units sold — in this case, 2/22.

This configuration is used when a virtual dorm bed type is linked to a physical dorm bed type. It supports selling dorm inventory in multiple ways (e.g., mixed dorm, all female, all male) while ensuring that occupancy and revenue are calculated correctly; when 1 bed is booked under one type, all of the other types are blocked for sale.

Below is an example of a property that has 5 physical dorm beds and 5 virtual dorm bed types. Its total Capacity is 5.

This screenshot shows DORM BEDS 5 VIRTUAL linked to the physical room type DORM BEDS 5:

This is how it would look on a report (Scenario 1):

How to read the report?

1. There’s a reservation for the DOV(1) (virtual dorm bed) on 2025-09-26.
2. DORM BEDS 5 (physical) has capacity, while DORM BEDS 5 VIRTUAL does not.
3. DOV(1) is not marked as sold but has the revenue associated with the booking.
4. DOR(1) (physical) is marked as sold but does not have revenue associated.
5. Occupancy is calculated as 1/5 = 20%.

This is how it would look on a report (Scenario 2):

1. There’s a reservation for DOR(1) (physical dorm bed) on 2025-09-24.
2. DORM BEDS 5 has capacity, while DORM BEDS 5 VIRTUAL does not.
3. DOR(1) is marked as sold and has the revenue associated with the booking.
4. DOV(1) is not marked as sold and does not have revenue associated.
5. Occupancy is calculated as 1/5 = 20%.

This tiered configuration links a virtual room to a physical unit, which then links to another virtual room. While technically supported, this setup is not recommended due to potential occupancy mismatches and reporting inconsistencies.

Because the final booked unit is virtual, the associated physical rooms may not be counted correctly toward occupancy.

Below it's an example of a property that has 16 physical rooms and 11 virtual rooms. Its total Capacity is 16.

This screenshot shows the VR5(1) linked to PH3(1), which is further linked to another virtual room VR6(1).

This is how it would look on a report:

How to read the report?

1. 1. There is a reservation for the VR5(1) virtual room with a stay date of 2025-05-24.
   2. VR5(1) is not marked as sold and has no capacity, but has the revenue associated with the booking.
   3. The intermediate physical room PH3(1) is marked as sold and has capacity, but shows no revenue associated (the revenue is associated with the actual booked virtual room).
   4. The linked virtual room VR6(1) shows neither occupancy, nor capacity, or revenue.
   5. Occupancy is calculated based on the physical units sold — in this case, 1/16 = 6.25%.

This tiered configuration links a physical room to another physical room, which then connects to a virtual unit. While it allows some inventory modeling flexibility, this setup results in no occupancy being recorded — even when the virtual unit is booked.

This behavior occurs because the final unit in the booking chain is virtual, and the intermediary physical connections do not register occupancy in the reports.

Below it's an example of a property that has 16 physical rooms and 11 virtual rooms. Its total Capacity is 16.

This screenshot shows PH8(1) linked to PH9(1), which is further linked to the virtual unit V10(1).

This is how it would look on a report:

How to read the report?

1. 1. There is a reservation for the V10(1) virtual unit on 2025-05-28.
   2. V10(1) is not marked as sold and has no capacity, but it shows the full revenue amount.
   3. Neither PH8(1) nor PH9(1) are marked as sold, nor do they reflect any revenue or occupancy data.
   4. Despite the revenue appearing, occupancy is 0/16 = 0% because no physical room was marked as sold.

This configuration links a physical room to a virtual unit, which is then linked to a second virtual unit. It may appear in legacy configurations or setups that attempt to stack multiple virtual representations for the same physical inventory.

This structure is not recommended, as it leads to inaccurate reporting. Occupancy may be undercounted or misreported because only physical units are counted for occupancy, and the multiple virtual layers obscure the connection.

Below it's an example of a property that has 16 physical rooms and 11 virtual rooms. Its total Capacity is 16.

This screenshot shows PH4(1) and PH4(2) linked to VR(1), which is then linked to VR8(1).

This is how it would look on a report:

How to read the report?

1. 1. There is a reservation for the final virtual unit Virtual 8 with a stay date of 2025-05-26.
   2. Virtual 8 is not marked as sold, shows no capacity, but has the full revenue associated with the booking.
   3. Virtual 7 is also linked to the same physical room type but is not booked — it shows no revenue, no capacity, and is not marked as sold.
   4. The physical units PH4(1) and PH4(2) are both marked as sold (Rooms Sold = 2), and have full capacity, but show no revenue (the revenue is associated with the actual booked virtual room).
   5. Occupancy is correctly calculated based on the physical units sold — in this case, 2/16 = 12.5%.

This configuration reflects a legacy setup where a physical room is directly linked to a virtual room. It was common during older Shared Inventory migrations.

Although technically supported (it gives correct reporting on physical rooms), this structure can result in overbookings or double-counting because physical inventory may be oversold if not carefully monitored.

Below it's an example of a property that has 16 physical rooms and 11 virtual rooms. Its total Capacity is 16.

This screenshot shows PH5(1) and PH5(2) both linked to a single virtual room: VR9(1).

This is how it would look on a report:

How to read the report?

1. 1. There is a reservation for the virtual unit VR9(1) on 2025-05-25.
   2. VR9(1) is not marked as sold, shows no capacity, but holds the full revenue.
   3. The physical units PH5(1) and PH5(2) are correctly marked as sold and contribute to occupancy, but have no revenue associated (the revenue is associated with the actual booked virtual room).
   4. Occupancy is correctly calculated based on the physical units sold — in this case, 2/16 = 12.5%.

This configuration links one physical room to another physical room. It is not a recommended or supported setup, as it causes inconsistent occupancy reporting.

In this setup, only the booked physical room is marked as sold, while the linked physical remains available. This means that occupancy will only ever count one physical room, even though two rooms are linked.

Below it's an example of a property that has 2 physical rooms and no virtual rooms. Its total Capacity is 2.

This screenshot shows Toucan Room (TR1) linked directly to another physical room: Colibri Room (CR1).

Example 1: Reservation for Toucan Room

This is how it would look on a report:

How to read the report?

1. 1. There is a reservation for Toucan Room (TR1) with a stay date of 2025-08-21.
   2. Toucan Room is marked as sold and has revenue associated with it.
   3. Colibri Room remains available and is not marked as sold.
   4. Revenue is associated with Toucan Room only.
   5. Occupancy is calculated as 1/2 = 50%.

Example 2: Reservation for Colibri Room

This is how it would look on a report:

How to read the report?

1. 1. There is a reservation for Colibri Room (CR1) with a stay date of 2025-08-22.
   2. Colibri Room is marked as sold and has revenue associated with it.
   3. Toucan Room remains available and is not marked as sold.
   4. Revenue is associated with Colibri Room only.
   5. Occupancy is calculated as 1/2 = 50%.

This configuration links two physical rooms as primaries to two other physical rooms as secondaries. It is a legacy-style setup that often results in inaccurate occupancy reporting, since multiple physical rooms may be counted as sold from a single booking.

Below is an example of a property with 16 physical rooms and 11 virtual rooms, giving it a total Capacity of 16.

In this screenshot, PY6(1) and PY6(2) are configured as primary physical units, directly linked to PH7(1) and PH7(2) as secondary physical units:

This is how it would look on a report:

How to read the report?

1. 1. There is a reservation for PY6(1) with a stay date of 2025-05-27.
   2. PY6(1) is marked as sold and has the revenue associated with it.
   3. PH7(1) and PH7(2) are also marked as sold, but do not carry revenue. Revenue remains with the actual booked unit.
   4. Both Physical 6 and Physical 7 have capacity, but the occupancy calculation only counts 3/16 units sold.
   5. Issue: Not all four linked physical units are counted as sold. This leads to inaccurate occupancy, making the configuration unsupported.

• Possible Cause: Your property might be using an unsupported legacy Split Inventory configuration that leads to incorrect metrics.
• Solution Steps:
  1. Review your Split Inventory configurations.
  2. Identify if any configurations fall under the "Unsupported Split Inventory Configurations" as outlined in this article.
  3. Update your configurations to one of the supported types:
     1. Virtual → Virtual → Physical
     2. Virtual → Physical and Virtual → Physical
     3. Virtual → Virtual and Virtual → Physical
     4. Virtual → Virtual
     5. Virtual → Physical (Room to Room scenario)
     6. Virtual → Physical (Dorm Beds to Dorm Beds scenario)