Accounting Principles

The following document outlines the accounting principles used in RezOvation GT, including:

• Revenue Recognition Methods
• Advance Deposit Liabilities
• Gift Certificates.

Revenue Recognition Methods

Overview

The revenue recognition method can be set by navigating to Configuration > Revenue Accounts.

Each Night of the Reservation

• Revenue is recognized on each night of the reservation.
• Payments are NOT considered when calculating revenue.
• Payments taken in advance of the reservation arrival are considered liabilities (also known as advance deposits)
• On each night of the reservation:
  • Revenue is increased by the amount of the nightly room charges and any extra charges applied to the given room night
  • Advance deposit liabilities are decreased by the amount of the nightly room charges and any extra charges applied to the given room night up to the total amount of any advance deposits
  • Accounts receivable are increased by the amount of the nightly room charges and any extra charges applied to the given room night for which no payment has been received.

EXAMPLE:

1. 4/1: reservation is made for 2 nights @ $100 / night, for $200 total. Guest pays a $50 deposit up front.
   • Payment is taken for $50, and balance of the invoice is $150.
   • Advance deposit liabilities are increased by $50.
2. 5/1: Guest arrives.
   • Room revenue is recognized for $100.
   • Advance deposit liabilities are decreased by $50 (amount of deposit).
   • Accounts receivable is increased by $50.
3. 5/2: Guest stay continues. Guest also purchases $50 of alcohol.
   • Room revenue is recognized for $100, and food & beverage revenue is recognized for $50. Total room revenue = $200, total food & beverage revenue = $50.
   • Accounts receivable is increased by $150. Total Accounts receivable = $200.
4. 5/3: Guest checks out. Payment is taken for $200, and balance of invoice is $0.
   • Accounts receivable is decreased by $200.
   • Total room revenue = $200, total food & beverage revenue = $50.

Departure Date

• Revenue is recognized on departure date of reservation.
• Payments are NOT considered when calculating revenue.
• Payments taken in advance of the reservation arrival are considered liabilities (also known as advance deposits)
• On departure date of the reservation:

1. • Revenue is increased by the amount of the room charges and any extra charges applied to the invoice
   • Advance deposit liabilities are decreased by the amount of the nightly room charges and any extra charges applied to the invoice up to the total amount of any advance deposits
   • Accounts receivable are increased by the amount of the nightly room charges and any extra charges applied to the invoice for which no payment has been received.

EXAMPLE:

1. 4/1: Reservation is made for 2 nights @ $100 / night, $200 total. Guest pays a $50 deposit up front.
   • Payment is taken for $50, and balance of invoice is $150.
   • Advance deposit liabilities are increased by $50.
2. 5/3: Guest checks out. Payment is taken for $150, and balance of invoice is $0.
   • Room revenue is recognized for $200.
   • Advance deposit liabilities are decreased by $50.

When Final Payment is Received

• Revenue is always recognized on the most recent payment date.
• Revenue is always recognized whenever there is a negative or 0 balance.
• Revenue recognition algorithm takes effect whenever the invoice changes.
• If revenue has already been recognized for an invoice, and additional items are added to the invoice, then:
  • If the item added to the invoice causes the balance of the invoice to become greater than 0, then revenue is NOT recognized for that item.
  • Items on the invoice for which revenue has already been recognized are NOT affected, and the revenue recognition date for this items remains the same.
  • When the balance of the invoice becomes negative or 0, revenue is recognized for the additional item(s).
• Refunds and voids do not affect the revenue recognition algorithm. i.e. if revenue is recognized on an invoice, and then a refund is applied, the revenue is still recognized even though the invoice balance is > 0. This can be corrected by adjusting the charges on the invoice so that the balance once again becomes 0.
• For reference, In Guest Tracker 3.x, the algorithm takes effect at the moment a line item or payment is added.

EXAMPLE:

1. 4/1: Reservation is made for 2 nights @ $100 / night, $200 total. Guest pays in full up front.
   • Payment is taken for $200, and balance of invoice is $0.
   • Revenue is recognized for $200.
2. 5/1: Guest arrives, and purchases food and beverages for at total of $100.
   • Balance of invoice increases to $100.
   • Total revenue recognized is still $200 (amount of original payment). Revenue recognition date remains 4/1.
3. 5/3: Guest checks out.
   • Payment is taken for $100 and balance of invoice is $0.
   • Revenue is recognized for $100.

NOTE: If a payment date is edited after the final payment is received, the revenue report is NOT affected, and the revenue recognition date will be unchanged. As such, we do NOT support editing payment dates after the final payment is received for an invoice.

Revenue Reports

General Notes

• Revenue calculations do not include tax
• Some revenue reports include tax information for reference only. For more detailed tax information, users should refer to the tax reports.
• Tax liability calculations match the revenue recognition method.  So, if you are recognizing revenue based on departure date, then the tax liability will not exist until the departure date (when the revenue is recognized).

Summary Report

• Daily sales calculations include tax
• Average daily rate is calculated based on room nights that occurred within the date range
• Occupancy percentage is calculated based on room nights that occurred within the date range, and does NOT include out of service units. Actual calculation is # of booked room nights / number of room nights in month)
• Advance deposit liabilities are calculated as of the end date of the report (e.g. if the report is for 1/1/2008 - 1/31/2008 then the end date is 1/31/2008). All liabilities outstanding as of the end date are included in the report. For this calculation the beginning date does not have any affect.
• Gift certificate liabilities are calculated the same as advance deposit liabilities. Note that GC liabilities are based on the sale price of the GC, NOT the face value. A few things to note:
  • GC liability is decreased when a GC is redeemed.
  • Initial GC liability is determined by the sale price.
  • If the GC face value is higher than the sale price (which is allowed), and the GC is redeemed, then the liability is decreased up to the amount of the sale price. So, GC liability can never be negative, even if the GC face value is, say, $150 and the sale price is $100.
  • Refunds to a GC will not increase the liability amount. Initial liability is determined by sale price, not by GC value, so this use case has no effect on GC liability.

Revenue by Source / Revenue by Reason for Stay

• Referral Source is referenced from the reservation referral source, not the contact referral source.
• Number of nights indicates the total number of room nights for the given date range.

Revenue By Room

• Displays the amount of revenue earned for each individual room. In order for this report to be accurate, the user must using rates, rather than add-on packages. e.g. any customer who calculates charges based on add-on packages will not see revenue reflected on the actual room, as there is no way to tie the revenue information directly to the room.
• Users importing from Guest Tracker may see inaccurate information on this report for any data imported from Guest Tracker. This is because Guest Tracker did not typically track revenue by room, but instead tracked revenue by package and by account. So, the user should instead refer to the Revenue by Account report.
• Revenue for extras or add-ons is NOT included in this report.

How Advance Deposit Liabilities are calculated based on revenue recognition method

• Advance deposits are closely tied to the revenue recognition method selected.
• For brevity, Advance Deposits is abbreviated AD in this document.

Advance deposit liabilities should follow the below rules, depending on the revenue recognition method selected:

All revenue recognition methods

Any payment taken before the reservation arrival date will increase Advance Deposits. e.g. a reservation is made on 6/1 for 12/1, and a payment of $100 is taken. This increases advance deposits by $100.

Recognize revenue on each night of the reservation

Advance deposits are decreased by the amount of the room charges (up to the total amount of the deposit) for each night of the reservation, starting with the arrival date.

• Example 1: $100 deposit, $100/night room charges, 2 nights
  1. 6/1 - Reservation for 2 nights @ $100/night is made for 12/1, and a payment of $100 is taken. AD is increased by $100.
  2. 12/1 - Reservation arrives. AD is decreased by $100.

• Example 2: $150 deposit, $100/night room charge, 2 nights
  1. 6/1 - Reservation for 2 nights @ $100/night is made on 6/1, and a payment of $150 is taken. AD is increased by $150.
  2. 12/1 - Reservation arrives. AD is decreased by $100.
  3. 12/2 - Reservation 2nd night (stayover) occurs. AD is decreased by $50.

Recognize revenue on departure date

Advance deposits are decreased by the amount of the room charges (up to the total amount of the deposit) on the reservation departure date.

• Example: $100 deposit, $100/night room charges, 2 nights
  1. 6/1 - Reservation for 2 nights @ $100/night is made for 12/1, and a payment of $100 is taken. AD is increased by $100.
  2. 12/1 - Reservation arrives. AD is not affected.
  3. 12/3 - Reservation departs. AD is decreased by $100.

Recognize revenue when final payment is received

Advance deposits are decreased by the amount of the room charges (up to the total amount of the deposit) when final payment for the reservation is received (i.e. the balance on the reservation is reduced to $0).

• Example 1: $100 deposit, $100/night room charges, 2 nights, final payment received on departure date.
  1. 6/1 - reservation for 2 nights @ $100/night is made for 12/1 - 12/3, and payment of $100 is taken. AD is increased by $100.
  2. 12/1 - Reservation arrives. AD is not affected.
  3. 12/3 - Reservation departs. Payment is received for $100, which brings the balance of the invoice to $0. AD is decreased by $100.

• Example 2: $100 deposit, $100/night room charges, 2 nights, final payment received on arrival date.
  1. 6/1 - Reservation for 2 nights @ $100/night is made for 12/1, and a payment of $100 is taken. AD is increased by $100.
  2. 12/1 - Reservation arrives. Payment is received for $100, which brings the balance of the invoice to $0. AD is decreased by $100.

• Example 3: $100 deposit, $100/night room charges, 2 nights, final payment received after departure date.
  1. 6/1 - Reservation for 2 nights @ $100/night is made for 12/1, and a payment of $100 is taken. AD is increased by $150.
  2. 12/1 - Reservation arrives. AD is not affected.
  3. 12/3 - Reservation departs. AD is not affected.
  4. Final payment is received for $100, which brings the balance of the invoice to $0. AD is decreased by $100.

Gift Certificate Accounting

There are two potential scenarios in terms of the life cycle of a gift certificate (GC).

GC sold and redeemed

In this scenario, no revenue is recognized for the GC, because the GC is simply used as a form of payment. Instead, revenue is recognized for the items (room charges, extras) for which the GC was used.

1. GC is sold and paid for
   • GC liability increases
2. GC is redeemed
   • GC liability decreases
   • Revenue is recorded for room / extra charges based on revenue recognition method used
   • No revenue is recorded for the GC

GC sold and expired (aka breakage)

1. GC is sold and paid for
   • GC liability increases
2. GC expires
   • GC liability decreases
   • Revenue is recorded for the GC

There is no complete way to handle all GC life cycle scenarios in RezOvation GT, since the software only deals with GCs as far as how they relate to room and extra revenue, not as far as how they relate to gift certificate revenue. In addition, each of the 50 U.S. states has different rules as to how GCs are handled when they expire (some states do not allow GCs to expire at all), so there are a number of different scenarios that must be handled manually by the user. The bottom line is that GCs are never considered revenue in RezOvation software, so if the user wants to expire a GC and recognize it as revenue, they need to do so in their accounting software.

From an accounting perspective, it works like this:

• GC is sold -- GC liability account is increased
• GC is redeemed -- GC liability account is decreased

Note that none of this affects revenue in RezOvation GT. Revenue works like this:

• Reservation is booked, and deposit (if required) is taken – no revenue is recorded
• Reservation arrives – revenue recorded based on revenue recognition method.

Gift certificate accounting for QuickBooks export

When a GC is sold:

• the GC liability account is increased
• the bank account is increased by the amount of the payment

When a GC is redeemed:

• the GC liability account is decreased by the amount of the GC.

Frequently asked questions about revenue reports

Why does my occupancy report not sync up with my revenue report?

Occupancy reports are always based on room nights within the date range of the report. Revenue, on the other hand, is dependent on the revenue recognition method. For example, if you generate a report for Jan, and you are recognizing revenue on departure date, and you have a reservation that arrives in Jan but departs in Feb, then you will see a portion of the occupancy in Jan, but no revenue. All the revenue will show in Feb. So:

• Report date = Jan 1 - Jan 31
• Reservation is 3 nights @ $100 / night
• Reservation arrives on Jan 30 and departs on Feb 2
• Occupancy report will show occupancy on Jan 30 and 31 for this reservation, for an average of $100 / night
• Revenue report will show no revenue for this reservation

In order for the reports to match more closely, the best option is to use the "each night" revenue recognition method, which will always report revenue in the month that the room night occurred, rather than on the departure date.

Can I change my revenue recognition method?

Yes. Changing the revenue recognition method does not change how the data is stored, only how it is reported. So you can change the revenue recognition method at any time.

The only exception is when exporting to QuickBooks. In this case, you should be consistent about using one revenue recognition method. Changing the revenue recognition method after having already exported data could cause the data sent to QuickBooks to be out of sync.

Does the revenue recognition method affect my QuickBooks export?

• Yes, for the IIF export method only. Data is exported to QuickBooks based on revenue recognition method when using IIF export.
• The automatic export is not affected by revenue recognition method.
• The option for When final payment is received is NOT supported with the IIF export.