Occupancy and Financial Reporting Calculations in Cloudbeds

Purpose Explain how Cloudbeds calculates occupancy, ADR, RevPAR, room revenue, and financial transactions, in alignment with the Uniform System of Accounts for the Lodging Industry (USALI), and where those calculations appear across the PMS.
Best for Managers and GMs, owners, Night Audit, Front Desk, and Revenue/PIE users.
Use this when You want to understand how a specific occupancy or financial figure was calculated, need to reconcile a report against another source, or want to confirm how Blocked, Out of Service, or Split Inventory rooms factor into your numbers.
Requirements None. This calculation logic applies automatically across your account.
Expected result You will be able to explain how your occupancy and financial figures were calculated, know where to look for each metric in the PMS, and interpret common report differences, such as negative values in the Daily Revenue Report.
Limitations Only the standard occupancy, ADR, and RevPAR calculations described in How occupancy, ADR, and RevPAR are calculated are available directly in the PMS. Adjusted or legacy-style calculations, described in Alternative and legacy-style views, require Cloudbeds Insights or specific pre-built reports.

Introduction

Cloudbeds calculates occupancy, ADR, RevPAR, room revenue, and financial transactions using the Uniform System of Accounts for the Lodging Industry (USALI), the standard framework hotels worldwide use to define and report these metrics consistently. USALI is not only a US accounting convention: it is the common reference point owners, investors, accountants, franchise brands, and industry benchmarking services use to compare one property's performance against another's, regardless of where that property is located.

Your Cloudbeds figures rarely stay inside the PMS. They get compared against an owner's expectations, an investor's model, a franchise brand's standards, or an industry benchmark report. When occupancy, ADR, and RevPAR are calculated the same way everywhere in Cloudbeds, those comparisons are more likely to line up, instead of requiring extra explanation for why one property's occupancy doesn't match another's.

This calculation framework is not limited to reports. It applies wherever these figures appear: the Calendar, Dashboard, PIE, Groups, Reporting, and Cloudbeds Insights.

This article explains how occupancy, ADR, RevPAR, and financial transactions are calculated, where each figure appears across the PMS, and how to interpret differences you may notice between reports, other properties, or external benchmarks.

  Cloudbeds moved to this calculation logic in December 2025. If you are reconciling reports from before that date, figures may not match this article. Contact Support if you need help interpreting historical data.

Table of contents

Why Cloudbeds aligns with USALI

USALI alignment means Cloudbeds speaks the same language as industry benchmarks, franchise reports, and other properties. It also reduces friction at month-end close and during external audits, since owners and accountants generally expect USALI-consistent reporting.

Who this affects, and how

The table below summarizes what this calculation logic means for each role. Each row links to where that topic is covered in more detail.

Role What to know
Front Desk Occupancy % on the Calendar includes Blocked and Out of Service rooms in availability.
Night Audit Transactions lock to their actual posting date. Use the Service Date field to reflect when a service was actually delivered, separate from when it was posted. See How financial transactions and accounting codes work.
Manager/GM The Daily Revenue Report and other financial reports may show payments as negative values. This is expected, not an error. See Payments may show as negative values in the Daily Revenue Report.
Owner Occupancy, ADR, and RevPAR follow USALI calculations, supporting comparability with benchmarking data and other properties. See Why Cloudbeds aligns with USALI.
Revenue/PIE users Occupancy-based pricing rules and alerts use the standard occupancy calculation. Review them if you rely on them. See PIE (Price Intelligence Engine).

How occupancy, ADR, and RevPAR are calculated

The formulas below apply consistently across every dashboard and report in the PMS.

  • Occupancy = Total Rooms Sold ÷ Total Rooms Available.
  • Blocked and Out of Service rooms are included in Total Rooms Available, per USALI. USALI only excludes long-term closures of six months or more. Since Cloudbeds does not have a "long-term" status, all Blocked and Out of Service rooms remain in the calculation.
  • ADR (Average Daily Rate) = Total Room Revenue ÷ Total Rooms Sold.
  • RevPAR (Revenue Per Available Room) = Total Room Revenue ÷ Total Rooms Available (including Blocked and Out of Service rooms).
  • Room Revenue excludes cancellation fees and both inclusive and exclusive taxes and fees.
  • Room-level and room-type data works with Split Inventory setups, counting physical rooms only. See Why occupancy numbers can be inaccurate when Split Inventory is misconfigured for a common configuration issue.

  Want occupancy without Blocked or Out of Service rooms? See Alternative and legacy-style views.

How financial transactions and accounting codes work

Financial transactions follow a consistent posting model designed for accuracy and auditability.

  • Posting date: transactions lock to their actual posting date. They cannot be backdated.
  • Service date: every transaction also carries a service date (which can be back-dated) reflecting when the service was actually delivered, separate from when it was posted. This is the field Night Audit uses to align a transaction with the date the service actually occurred.
  • Voided, deleted, or routed transactions post as equal and opposite reversing entries rather than edits to the original transaction, preserving a full audit trail. This means the original transaction and its reversal both remain visible in transaction lists and reports.
  • Transaction codes are reportable in Cloudbeds Insights for detailed financial filtering. See the transaction-code table immediately below.
  • Custom Transaction Codes and Custom General Ledger Codes, configured in the Accounting Module, travel with every transaction and are reportable alongside the predefined Cloudbeds Transaction Code. See Financial reports (Cloudbeds Reports) for where these appear.

Cloudbeds uses the following USALI codes to categorize transactions. Additional codes may be added over time.

Description Code
Room Rate 1000
Room Rate – Adjustment 1000A
Room Rate – Void 1000V
Room Revenue 1100
Room Revenue – Adjustment 1100A
Room Revenue – Void 1100V
No Show 1200
No Show – Adjustment 1200A
No Show – Void 1200V
Item & Service 2000
Item & Service – Adjustment 2000A
Item & Service – Void 2000V
Addon 3000
Addon – Adjustment 3000A
Addon – Void 3000V
Custom Item (POS) 4000
Custom Item (POS) – Adjustment 4000A
Custom Item (POS) – Void 4000V
Cancellation 5000
Cancellation – Adjustment 5000A
Cancellation – Void 5000V
Deposit Transfer 6000
Accounts Receivable Ledger Transfer 7000
Tax 8000
Tax – Adjustment 8000A
Tax – Void 8000V
Fee 8100
Fee – Adjustment 8100A
Fee – Void 8100V
Payment 9000
Refund 9000A
Payment – Void 9000V
Payment (Cash) 9100
Refund (Cash) 9100A
Payment (Cash) – Void 9100V
Payment (Bank Transfer) 9200
Refund (Bank Transfer) 9200A
Payment (Bank Transfer) – Void 9200V
Payment (Credit Card) 9300
Refund (Credit Card) 9300A
Payment (Credit Card) – Void 9300V
Routed Rate / Revenue / Cancellation / No Show / Item & Service / Addon / POS / Tax / Fee / Payment (Cash, Bank, Card) Append "R" to the base code (for example, 1000R)

In Cloudbeds Insights, each transaction carries a Cloudbeds Transaction Code and a Cloudbeds Transaction Description that map to the codes in the transaction-code table above:

Cloudbeds Insights transaction row showing the Cloudbeds Transaction Code and Cloudbeds Transaction Description fields. 

Where you'll see it in the PMS

Expand each area below to see how it reflects this calculation logic.

Calendar

On the Calendar, Blocked and Out of Service rooms stay in Total Rooms Available but are not counted as sold.

Calendar view showing a daily occupancy percentage with Blocked and Out of Service rooms retained in Total Rooms Available. 

Dashboard

On the Dashboard, Rooms Sold excludes held allotment blocks, and ADR uses Total Room Revenue instead of Room Rate.

Dashboard Occupancy widget and Forecast panel showing Rooms Sold, ADR, RevPAR, and Revenue. 

PIE (Price Intelligence Engine)

PIE uses the occupancy calculation described in How occupancy, ADR, and RevPAR are calculated. Capacity, Available, and Sold counts include only physical rooms (virtual rooms are excluded). Occupancy-based pricing rules and alerts rely on that same calculation. See Create, edit, or delete occupancy-based rules/alerts in PIE.

The Overview tab shows Occupancy, RevPAR, and ADR for the day:

PIE Overview tab showing Occupancy, RevPAR, ADR, and Room Nights Sold for the day. 

The Rate Manager grid shows daily occupancy percentages by room type:

PIE Rate Manager grid showing daily occupancy percentages by room type. 

Selecting a specific room type and date opens its accommodation details, including ADR and availability:

PIE Rate Manager accommodation details panel showing ADR, availability, and occupancy for a selected room type and date. 

The Rate Shopper tab compares your rates and occupancy against a competitor over a 90-day window:

PIE Rate Shopper tab showing a 90-day occupancy and rate comparison against a competitor property. 

Groups

On a Group Profile, Revenue equals Total Room Revenue (Room Rate, plus Additional Room Revenue, plus Adjustments), and Blocked and Out of Service rooms are not removed from Night Available.

Group Profile header showing Guests, Night Booked, Night Available, ADR, and Room Revenue. 

Financial reports (Cloudbeds Reports)

In Cloudbeds Reports, open the Financial folder to find predefined transaction-level reports such as Transaction Detail and Expanded Transaction Report with Details. These reports can display the predefined Cloudbeds Transaction Code fields described in How financial transactions and accounting codes work, along with Custom General Ledger Codes when they are configured for your property.

Start in the Financial folder to open the predefined report that matches the transaction detail you want to review:

Cloudbeds Reports Financial folder showing predefined financial reports available to open.

In detailed transaction reports, predefined and custom accounting codes appear as separate fields so you can distinguish Cloudbeds' internal transaction classification from codes configured for your property's accounting structure:

  • Cloudbeds Transaction Code: the predefined code assigned to an internal transaction type, used for tracking and categorizing different types of transactions.
  • Custom General Ledger Code: the code assigned to a specific general ledger account, used for tracking and categorizing different types of financial transactions. Requires proper configuration in the PMS.

In this Expanded Transaction Report with Details, the Cloudbeds Transaction Code and Custom General Ledger Code columns are displayed together for each transaction:

Expanded Transaction Report with Details showing Cloudbeds Transaction Code and Custom General Ledger Code columns for individual transactions.

 The + Add option and Glossary are available only with Builder capabilities in Cloudbeds Insights. Predefined Cloudbeds Reports are view-only; to add or change fields, first use Save As to create an editable copy or create a new report.

If you have Cloudbeds Insights and want to add or remove one of these fields, open an editable report created with Save As or create a report from scratch. Then use the numbered areas in the image below:

  1. In Table Outline, under Columns, select + Add.
  2. Select Glossary if you want to review the available Cloudbeds Data Fields and confirm which field matches the information you need.
  3. Search for Code in the Glossary to narrow the available fields.
  4. Under Financial, select the + icon next to a field to review its definition, such as Cloudbeds Transaction Code or Custom General Ledger Code.
  5. In the Columns list, select the checkbox next to a field to add it to the report, or clear the checkbox to remove it.

The example below shows how to use the Glossary to understand the code fields available under Financial, then use the Columns checkboxes to control which fields appear in the report:

Editable Cloudbeds Insights financial report showing the Columns panel, Glossary search for code fields, Financial field definitions, and checkboxes used to add or remove report columns.

Interpreting and reconciling your data

Most support questions about occupancy and financial reporting come down to a handful of expected behaviors that look surprising the first time you see them. Expand the topic that matches what you are troubleshooting before assuming a report is wrong. Many of these topics point to a specific report rather than a screen; for the full list of report articles organized by category, see the Reporting Directory.

Payments may show as negative values in the Daily Revenue Report

  This is expected behavior, not an error. The Daily Revenue Report totals as Debits minus Credits, and reversals post as opposite transactions rather than edits to the original entry.

Example: a $100 room charge (Debit) and a $100 payment (Credit) will show as $0.00, not $100 and $100 separately.

If a negative number looks wrong (not just unfamiliar), check for:

  • Manual negative entries on a folio (an intentionally entered negative charge).
  • Reversals or adjustments that net to a credit.

Cross-check against the Total Debits and Credits by Month report to confirm charges and payments balance over time. If a discrepancy persists after checking these, contact Support.

Here's an example of how negative values appear in the Daily Revenue Report when debits and credits net together:

Daily Revenue Report showing negative payment values in the Revenue by Payment section, with an orange box highlighting the negative transaction amounts.

Why occupancy numbers can be inaccurate when Split Inventory is misconfigured

 Occupancy reporting depends on how physical and virtual accommodations are linked in Split Inventory. Unsupported or legacy configurations can cause Rooms Sold to be counted incorrectly, resulting in inaccurate or misleading occupancy percentages.

In supported Split Inventory configurations, occupancy is calculated from the physical rooms associated with the booking. Virtual rooms do not add capacity or Rooms Sold themselves, even when the revenue remains associated with the virtual room that was booked.

A Physical-to-Physical configuration is one example of a setup that can produce misleading occupancy. In the configuration below, Toucan Room (TR1) is linked directly to Colibri Room (CR1):

Split Inventory configuration showing Toucan Room linked directly to Colibri Room in a Physical-to-Physical setup.

When Toucan Room is booked, only that physical room is marked as sold. Colibri Room remains available even though the rooms are linked. The report therefore counts 1 room sold out of a total capacity of 2, resulting in 50% occupancy:

Occupancy report for a Physical-to-Physical Split Inventory setup showing Toucan Room sold, Colibri Room available, and total occupancy of 50 percent.

If your occupancy figures do not match the physical rooms you expect to be counted, review your Split Inventory configuration before troubleshooting the report itself.

See How do Occupancy Metrics work with Split Inventory for supported configurations, additional examples, and troubleshooting guidance.

If you migrated from Shared Inventory, see the Shared to Split Inventory Migration Guide.

No single built-in report combines all debits, credits, and payment methods

If you need one consolidated view of charges, payments, and payment methods, there is not a single predefined Cloudbeds Report that combines all of this information in one output. Choose the approach that best matches how you plan to use the data:

  • Use the Daily Revenue Report for a month-end summary. Set the report date to the last day of the month and use the Month-to-Date column to review the month's activity, including the payment-method section. Payments appear as negative entries in this report. See Payments may show as negative values in the Daily Revenue Report.
  • Export and combine the relevant reports outside Cloudbeds PMS. For example, you may export Payment Ledger for payment details, Taxes and Fees for tax and fee amounts, and Add-ons, Items, and Services Sold for product or service revenue. You can then combine and analyze the exported files in Excel, Google Sheets, or the accounting or reporting system your organization uses. See Export financial data from Cloudbeds PMS to an external accounting system.
  • Use Cloudbeds Insights for a reusable custom reporting workflow. With the appropriate Builder capabilities and permissions, you can create or copy a report, choose the financial fields you need, adjust groupings and filters, and save the customized configuration for future use. See Cloudbeds Insights overview.

If your accounting workflow uses Custom Transaction Codes or Custom General Ledger Codes, include those fields when available so exported or customized reporting can be matched more easily to the corresponding accounts in your external accounting system.

Alternative and legacy-style views

If you need occupancy or ADR calculated differently from the PMS default, these alternatives are available:

  • In Cloudbeds Insights, build an Adjusted Occupancy field using Builder: Total Rooms Sold ÷ (Capacity − Blocked − Out of Service).
  • In Cloudbeds Insights, build a legacy-style ADR field using Builder: Room Rate ÷ Total Rooms Sold.
  • Without Cloudbeds Insights, from the Main Menu Main menu icon.png select Reporting Reporting icon.png, then from the Home tab use the Search Reports bar (or go to Cloudbeds Reports and use the search bar or filter) to find any of the pre-built reports below. All of them exclude Blocked and Out of Service rooms:
    • Occupancy by Room Type - Last Month
    • Occupancy Comparison (Month or Today)
    • Occupancy History and Forecast (and by Room Type or Source)
    • Occupancy Statistics (and variants)
    • Production Report (and variants)
    • Rooms Sold and Occupancy (and by Month or Today)

Cloudbeds Insights also exposes two data fields tied to the transaction codes in the transaction-code table within How financial transactions and accounting codes work: Cloudbeds Transaction Code and Cloudbeds Transaction Description. In the Occupancy Data Set specifically, these codes are grouped into broader buckets. For example, "Total Room Revenue" combines Room Rate, Other Room Revenue, and their adjustments.

Cloudbeds Insights report showing Total Room Revenue, Other Room Revenue, Total Miscellaneous Income, and Total Other Revenue by month. 

Frequently asked questions

This section answers two common questions: whether definite allotment blocks count toward occupancy, and how the standard occupancy calculation affects PIE occupancy-based rules and alerts.

Are definite allotment blocks included in the occupancy calculation?

No. Occupancy counts only rooms actually sold via reservations. The rooms available count does not exclude allotment blocks, blocks, or out of service rooms.

How do occupancy-based PIE rules interact with the standard occupancy calculation?

Because Blocked and Out of Service rooms are included in Total Rooms Available, occupancy-based pricing rules and alerts in PIE reflect that same inclusion. If a rule or alert doesn't behave as you expect, confirm it accounts for Blocked/OOS rooms before troubleshooting further. See Create, edit, or delete occupancy-based rules/alerts in PIE.


These related guides provide deeper insight into key areas that affect your occupancy, ADR, RevPAR, and financial calculations:

Was this article helpful?
0 out of 0 found this helpful

Comments

2 comments
  • Why was this not added as an integration option? Other large PMS providers allow for an integration to meet USALI standards if required. This affects all past reporting, PIE strategies/rules, and generally how Cloudbeds operates and reports. Insights, Classic Reports, and every different area where these statistics are being reported are all different. There is no consistency within the PMS, so to change how you display and report these statistics seems very counterintuitive.

    0
  • Hello, Jeff Delgado, 

    Thank you so much for sharing your feedback about Cloudbeds Reports.

    We understand how crucial accurate data is for your operations. Our team is currently prioritizing and actively working on optimizing our reporting features, and we're committed to providing you with the best possible experience.

    If you have specific examples or details regarding the inconsistencies you've encountered, we encourage you to contact our Support Team directly. This will allow us to investigate your concerns more thoroughly and provide you with targeted assistance.

    We appreciate your suggestions as we continue to enhance our platform.

    Regards!

    0

Please sign in to leave a comment.