> For the complete documentation index, see [llms.txt](https://docs.new-vue.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.new-vue.com/glossary/calculations/overvue-calculations.md).

# OverVue Calculations

## Attendance

<details>

<summary>Attendees</summary>

This shows the total number of attendees listed in the Attendance table for the current view, using each record's own date. All other attendance measures are based on this number.

</details>

<details>

<summary>Attendees - year to date</summary>

This is a Year-to-Date calculation for Attendees. It finds the latest date in view (either today or the last filtered date), checks which fiscal year that date is in (currently January 1st to December 31st), and totals Attendees from the start of that fiscal year up to the latest date. If a Season is selected, it only uses the season's latest date to choose the fiscal year, but still starts counting from January 1st of that year.

</details>

<details>

<summary><mark style="color:$danger;">Attendees - year to date previous year (cards)</mark></summary>

<mark style="color:$danger;">Flag</mark>

</details>

<details>

<summary>Attendees - year-over-year growth as a percentage</summary>

This shows Attendees for the current period compared to Attendees LY (which is shifted back 364 days, or 52 weeks, so it matches the same weekday as last year.. The result is shown as a percent change: (this period minus the 364-days-ago period) divided by the 364-days-ago period. If there is no prior-year figure, it returns blank instead of an error.

</details>

<details>

<summary><mark style="color:$danger;">Attendees - year to date year over year growth as a percentage</mark></summary>

<mark style="color:$danger;">Flag</mark>

</details>

<details>

<summary>Attendees LY</summary>

Attendees using the 364-day shift means looking 52 weeks back instead of a full calendar year. This way, the comparison matches the same day of the week as the current period, not the same calendar date. Over a leap year, the dates drift further apart. The current year's date window is shifted back 364 days, so the comparison matches the same weekday as today, not the same calendar date.

</details>

<details>

<summary>Attendees - year to date (Cards)</summary>

This is a season-aware Year-to-Date calculation for Attendees. It checks if a Season filter is being used by comparing the filtered date range to the full range. If a season is selected, the window is that season's first date through its last date. If no season is selected, the window is January 1st of the current year through today. If today is the 1st of a month, it uses yesterday as the cutoff to avoid a low or blank total before that day's data is available.

</details>

<details>

<summary>Attendance Pace - LY</summary>

This is a pace calculation for Attendees. It shifts the entire date window back 364 days (52 weeks, not a full calendar year). It also only includes booking items that were already created as of that 364-day-back cutoff. This shows how much attendance was already confirmed by the same point in last year's booking cycle. It is a booking-pace comparison, not just a calendar comparison.

</details>

<details>

<summary>Attendees - whole of previous year</summary>

This calculates Attendees for the entire previous year, not using a 364-day shift. It uses the full prior fiscal year, from January 1st to December 31st under current settings, or the full season window if a Season is selected. If the window cannot be resolved, it returns 0 instead of an error.

</details>

<details>

<summary>Attendees Week To Date</summary>

Attendees from Monday of the current week through the latest date in view.

</details>

<details>

<summary>Attendees Month To Date</summary>

Attendees from the 1st of the current calendar month through the latest date in view.

</details>

<details>

<summary>Attendees Quarter To Date</summary>

Attendees from the 1st of the current calendar quarter through the latest date in view.

</details>

<details>

<summary>Attendees Same Day Last Week</summary>

Attendees for the single day exactly 7 days before the latest date in view.

</details>

## Weather

<details>

<summary>Temperature - highest</summary>

This is the highest temperature (°F) recorded in the weather readings you see.

</details>

<details>

<summary>Temperature - highest last year</summary>

This is the highest recorded temperature (°F) from 52 weeks ago, so it matches the same day of the week as the current period, not the same calendar date. Over a leap year, the dates may drift further apart.

</details>

<details>

<summary>Temperature - average</summary>

This is the average temperature (°F) from the weather readings you see. It is a simple average based on the days you have selected.

</details>

<details>

<summary>Precipitation %</summary>

This shows the percentage of weather readings that recorded precipitation. It is calculated by dividing the number of readings with precipitation by the total number of readings in view. If there are multiple readings per day, those days will have a bigger impact on the percentage.

</details>

## Item

<details>

<summary>Items sold - count</summary>

This shows the total number of items or tickets sold, based on what you are currently viewing. Each sale is counted by the date the item was used.

</details>

<details>

<summary>Items - discount total</summary>

This is the total dollar discount given at the individual item level, not at the booking level, for what you are viewing. For details on the difference between item-level and booking-level discounts, see the Discount folder.

</details>

<details>

<summary>Items Sold - previous year</summary>

Items Sold using a 364-day shift, which means looking 52 weeks back instead of a full calendar year. This way, the comparison matches the same day of the week as the current period, though not the same calendar date. Over a leap year, the dates will drift further apart.

</details>

<details>

<summary>Items Sold - year over year growth as a percentage</summary>

This shows the percent change in Items Sold for the current period compared to the previous year.

</details>

<details>

<summary>Items Sold - year to date</summary>

This is a Year-to-Date calculation for Items Sold. It finds the latest date in view (either today or the last filtered date), checks which fiscal year that date is in (currently January 1st to December 31st), and totals Items Sold from the start of that fiscal year up to the latest date. If a Season is selected, it still uses the season's latest date to pick the fiscal year, but always starts counting from January 1st of that year.

</details>

<details>

<summary>Items Sold - year to date (Cards)</summary>

This is a season-aware Year-to-Date calculation for Items Sold. It checks if a Season filter is being used by comparing the filtered date range to the full range. If a season is selected, it uses that season's first and last dates. If no season is selected, it uses January 1st of the current year through today. However, if today is the 1st of a month, it uses yesterday as the cutoff to avoid a low or blank total before today's data is complete.

</details>

<details>

<summary>Items Sold - year to date previous year (Cards)</summary>

Items Sold - year to date (Cards), shifted back 364 days, which is 52 weeks instead of a full calendar year. This means the comparison matches the same day of the week as the reference period, not the same calendar date. Over a leap year, the dates will drift further apart. This gives last year's season or fiscal-year-to-date window by weekday alignment.

</details>

<details>

<summary>Items Sold - YTD YoY %</summary>

This shows the percent change between Items Sold - year to date (Cards) and Items Sold - year to date previous year (Cards).

</details>

<details>

<summary>Items Sold - whole of previous year</summary>

This is a whole-of-previous-year calculation for Items Sold. It is not a 364-day shift, but instead is calculated as the entire prior fiscal year, from January 1st to December 31st of last year (under current settings), or the full season-length window if a Season is selected.

</details>

<details>

<summary>Items sold - count WTD.</summary>

This is a week-to-date calculation for Items Sold. It counts from Monday of the current week (using Monday-start, ISO-style week numbering) through the latest date in view.

</details>

<details>

<summary>Items sold - count MTD</summary>

This is a month-to-date calculation for Items Sold, using DAX's standard calendar month-to-date logic. It counts from the 1st day of the current month through the latest date in view. This is a true calendar-date comparison, so month-to-date through the 31st is compared to month-to-date through the 31st of the reference period, not by weekday.

</details>

<details>

<summary>Items sold - count QTD.</summary>

This is a quarter-to-date calculation for Items Sold. It counts from the 1st day of the current calendar quarter (January 1st, April 1st, July 1st, or October 1st) through the latest date in view.

</details>

<details>

<summary>Items sold - count Same Day LW</summary>

This is a same-day-last-week calculation for Items Sold. It compares a single day exactly 7 days before the latest date in view, matching the same weekday one week earlier, rather than a range.

</details>

## Payments

<details>

<summary>Payments</summary>

This is the total dollar amount from Booking Payment records. It does not include money added to gift cards, but it does include gift card redemptions and refunds, which lower the total. The date used is when the payment record was created, not when the booking happens. If you notice a low Payments figure during heavy gift card activity, this is the reason.

</details>

<details>

<summary>Payments - whole of previous year</summary>

This calculation shows Payments for the entire previous fiscal year, from January 1st to December 31st under current settings. If a Season is selected, it uses that season's full date range instead. This is not a 364-day shift, but a true full-year total.

</details>

<details>

<summary>Payments - year to date</summary>

This is a Year-to-Date calculation for Payments. It uses the latest date in view (either today or the last filtered date), finds which fiscal year that date belongs to (currently January 1st to December 31st), and totals Payments from the start of that fiscal year up to the latest date. If a Season is selected, it only uses the season's latest date to pick the fiscal year, but still starts counting from January 1st.

</details>

<details>

<summary>Payments - year to date previous year (cards)</summary>

<mark style="color:$danger;">FLAG</mark>

</details>

<details>

<summary>Payments - year to date year over year growth as a percentage (cards)</summary>

This compares Payments - year to date (Cards) with Payments - year to date previous year (cards). Because the previous-year figure is currently using the incorrect Booked Revenue measure, this percentage is not a true year-over-year Payments comparison until the source measure is fixed.

</details>

<details>

<summary>Payments - year-over-year growth as a percentage</summary>

This shows Payments for the current period compared to Payments from last year, shifted back 364 days (52 weeks) instead of a full calendar year. This means the comparison matches the same weekday, not the same calendar date, and is shown as a percent change.

</details>

<details>

<summary>Payments - year to date (Cards)</summary>

This is a season-aware Year-to-Date calculation for Payments. It checks if a Season filter is applied by comparing the filtered date range to the full range. If a season is selected, Payments are totaled from that season's first to last date. If no season is selected, the window is January 1st of the current year through today. If today is the 1st of a month, yesterday is used as the cutoff to avoid a low or blank total before that day's data is complete.

</details>

<details>

<summary>Payments - last year</summary>

Payments are calculated using a 364-day shift, which means looking back 52 weeks instead of a full calendar year. This way, the comparison matches the same day of the week as the current period, but not the same calendar date.

</details>

<details>

<summary>Payments - Growth</summary>

This is the dollar difference between this period's Payments and Payments - last year (using the 364-day-shifted figure). It is shown as a raw dollar amount, not a percentage.

</details>

<details>

<summary>Payments budget variance</summary>

This is Payments minus Budget for the period in view. It is a direct dollar-for-dollar comparison, not a percentage.

</details>

<details>

<summary>Payments - average per employee</summary>

Payments are divided by the total Employee count. Note that this count includes all employees, whether active or inactive (see the Employee folder). If the Employee table has inactive or terminated staff, the average will be lower.

</details>

<details>

<summary>Payments WTD</summary>

This is a week-to-date calculation for Payments. It totals Payments from Monday of the current week (using Monday as the start, following ISO week numbering) through the latest date in view.

</details>

<details>

<summary>Payments MTD</summary>

This is a month-to-date calculation for Payments, using DAX's standard calendar logic. It totals Payments from the 1st day of the current month through the latest date in view. This is a true calendar-date comparison, so month-to-date through the 31st is compared to the 31st of the reference period, not by weekday.

</details>

<details>

<summary>Payments QTD</summary>

This is a quarter-to-date calculation totals Payments from the 1st day of the current quarter (January 1st, April 1st, July 1st, or October 1st) through the latest date in view.

</details>

<details>

<summary>Payments Same Day LW</summary>

This is a same-day-last-week calculation for Payments. It compares a single day, exactly 7 days before the latest date in view, to the same weekday one week earlier. This is not a range, but a direct day-to-day comparison.

</details>

## Item Revenue

<details>

<summary>Item revenue when sold</summary>

Booked Revenue (Amount minus Discount, tax-exclusive; see the Booked Revenue folder), but dated by when each line item was created or sold instead of when it was used. This is the only figure in the model that answers "how much did we sell in this window," while all other revenue measures answer "how much revenue was used or redeemed in this window."Item revenue when sold - previous year\
Item revenue when sold using the 364-day shift, which means 52 weeks back instead of a full calendar year. This way, the comparison falls on the same day of the week as the current period, but not the same calendar date, and it drifts further off during a leap year.

</details>

<details>

<summary>Item revenue when sold - year-over-year growth as a percentage</summary>

Item revenue when sold compared to its previous-year figure, shown as a percent change. There is one deliberate difference: a decline is never shown as negative. The formula is: if growth is positive, show it; otherwise, show zero. So, if sold revenue is down year over year, it will display as 0% here instead of a negative percentage.

</details>

<details>

<summary>Item revenue when sold - year to date</summary>

This is a Year-to-Date calculation for Item revenue when sold. It finds the latest date currently in view (today, or the last date within any filter), determines which fiscal year that date falls in based on the model's fiscal-year settings (currently January 1st to December 31st), and totals Item revenue when sold from the start of that fiscal year through the latest date. If a Season is selected, it does not use the Season's own start date. Instead, it uses the season's latest date to pick the right fiscal year, then still starts counting from January 1st of that year.

</details>

<details>

<summary>Item revenue when sold - year to date previous year (Cards)</summary>

Item revenue when sold - year to date (Cards), shifted back 364 days, which is 52 weeks instead of a full calendar year. This means it lands on the same day of the week as the reference period, but not the same calendar date, and it drifts further off during a leap year.

</details>

<details>

<summary>Item revenue when sold - year to date (Cards)</summary>

This is a season-aware Year-to-Date calculation for Item revenue when sold. It checks if a Season filter is narrowing the report by comparing the filtered date range to the full unfiltered range. If a season is selected, the window for Item revenue when sold is from that season's first date to its last date, whatever those dates are. If no season is selected, the window is January 1st of the current year through today. However, if today is the 1st of a month, it uses yesterday as the cutoff instead to avoid an artificially low or blank total before that day's data is fully available.

</details>

## Booking

<details>

<summary>Bookings - count</summary>

This is a count of unique bookings (Booking\[nv\_BookingId]) for whatever you are looking at. Each booking is counted only once, no matter how many line items or payments it has.

</details>

<details>

<summary>Booking - average value</summary>

This is the total booking value divided by the number of bookings. It shows the average dollar value for each booking.

</details>

<details>

<summary>Bookings - Value</summary>

This is the total booking value at the booking level. It is calculated as the sum of Booking\[Amount] minus the sum of Booking\[Discount]. This number can be different from item-level revenue figures (like Booked Revenue) if a booking's total amount does not match the sum of its line items. For example, a fully comped booking can show $0 here even if its line items have a nonzero list price.

</details>

<details>

<summary>Booking - value last year</summary>

This is the booking value using a 364-day shift, which means looking 52 weeks back instead of a full calendar year. This way, the comparison falls on the same day of the week as the current period, but not the same calendar date. Over a leap year, the dates will drift further apart.

</details>

<details>

<summary>Average # of bookings per customer visits</summary>

This measures the number of bookings with a customer ID, divided by the number of unique customers with a customer ID. Bookings without a customer (like walk-up or anonymous sales) are left out of both counts. So, this number only covers bookings linked to identified customers.

</details>

<details>

<summary>Avg Days to Second Visit</summary>

For each customer with at least one "New" booking and one "Repeat" booking, this finds the number of days between their first "New" and first "Repeat" booking. It then averages this gap across all customers who qualify. Customers without a repeat visit are not included at all.

</details>

<details>

<summary>Avg Days Between Visits</summary>

For each customer with more than one booking date, this takes their most recent booking date minus their earliest booking date, divided by the number of booking dates minus one. It then averages this gap across all customers who qualify. This does not use the New/Repeat tags from the previous measure. It only requires two or more booking dates.

</details>

<details>

<summary>Booking Tax</summary>

The total tax amount recorded on bookings (Booking\[Tax]) for whatever is in view.

</details>

## Per Cap

<details>

<summary>Per Cap</summary>

Booked Revenue divided by Attendees gives you revenue per attendee. If you want the "revenue per booking" calculation, see the Per Booking measure below.

</details>

<details>

<summary>Per Cap - Previous Year</summary>

Per Cap using the 364-day shift looks 52 weeks back instead of a full calendar year. This way, the comparison falls on the same weekday as the current period, though not the same calendar date. Over a leap year, the dates drift further apart.

</details>

<details>

<summary>Per Cap - whole of previous year</summary>

This calculation applies Per Cap to the entire previous fiscal year, from start to finish. It does not use a 364-day shift. Under current settings, this means January 1st to December 31st of last year, or the full season window if a Season is selected.

</details>

<details>

<summary>Per Cap - year to date</summary>

This is a Year-to-Date calculation for Per Cap. It finds the latest date in view (either today or the last filtered date), checks which fiscal year that date is in (currently January 1st to December 31st), and totals Per Cap from the start of that fiscal year to the latest date. If a Season is selected, it only uses the season's latest date to pick the fiscal year, but still starts counting from January 1st.

</details>

<details>

<summary>Per Cap - year to date (Cards)</summary>

This is a season-aware Year-to-Date calculation for Per Cap. It checks if a Season filter is active by comparing the filtered date range to the full range. If a season is selected, Per Cap is calculated from that season's first date to its last date. If no season is selected, the window is January 1st of the current year through today. However, if today is the 1st of a month, it uses yesterday as the cutoff to avoid low or missing totals before today's data is complete.

</details>

<details>

<summary>Per Cap - year to date previous year (Cards)</summary>

Per Cap - year to date (Cards), shifted back 364 days, looks 52 weeks back instead of a full calendar year. This means the comparison falls on the same weekday as the reference period, but not the same calendar date, and the dates drift further apart over a leap year. Unlike the Payments/Attendees measures above, this one is correctly based on Per Cap itself.

</details>

<details>

<summary>Per Cap - YTD YoY %</summary>

This shows the percent change between Per Cap - year to date (Cards) and Per Cap - year to date previous year (Cards).

</details>

<details>

<summary>Per Cap per Product</summary>

Booked Revenue divided by Attendees, but any Product-level filter is removed from the Attendees count only. Booked Revenue still uses the active Product filter. This is useful when viewing a page by product or attraction, as it shows a per-cap figure based on total site-wide attendance, not just attendance for that product.

</details>

<details>

<summary>Per Booking</summary>

Booked Revenue divided by Bookings count gives you revenue per booking. This calculation was previously called "Per Cap" before the term was changed to mean revenue per attendee.

</details>

<details>

<summary>Per Cap WTD</summary>

This is a week-to-date calculation for Per Cap. It covers Monday of the current week (using Monday-start, ISO-style week numbering) through the latest date in view.

</details>

<details>

<summary>Per Cap MTD</summary>

This is a month-to-date calculation that covers the 1st day of the current month through the latest date in view. This is a true calendar-date comparison, so month-to-date through the 31st compares to the 31st of the reference period, not by weekday.

</details>

<details>

<summary>Per Cap QTD</summary>

This is a quarter-to-date calculation that covers the 1st day of the current calendar quarter (January 1st, April 1st, July 1st, or October 1st) through the latest date in view.

</details>

<details>

<summary>Per Cap Same Day LW</summary>

This is a same-day-last-week calculation for Per Cap that compares a single day exactly 7 days before the latest date in view, matching the same weekday one week earlier instead of a date range.

</details>

## Labor

<details>

<summary>Labor spend</summary>

Total paid labor cost (Labor\[PaidTotal]) for the current view. If there are no results, the value is shown as 0.

</details>

<details>

<summary>Labor spend vs revenue as a percentage</summary>

Labor spend year-to-date divided by booked revenue year-to-date. This shows labor cost as a share of year-to-date revenue, using the standard Year-to-Date window from January 1st of the fiscal year with the latest date in view through that latest date, no matter which Season is selected.

</details>

<details>

<summary>Labor - Paid Total with Blanks</summary>

This total matches Labor spend, but does not include the +0 adjustment. If there are no labor records for a period, it returns a blank instead of 0. This measure is used internally for other Labor calculations and is not meant to be shown on its own.

</details>

<details>

<summary>Labor hours worked</summary>

Total regular hours (Labor\[Regular]) for the current view. Overtime and double-overtime hours are not included. This only counts regular hours, so it will understate total hours worked during periods with significant overtime.

</details>

<details>

<summary>Labor - Percentage of Booked Revenue</summary>

Labor spend divided by booked revenue for whatever is in view. This shows labor cost as a share of revenue at a specific point in time, not year-to-date.

</details>

<details>

<summary>Labor spend - year to date</summary>

This is a Year-to-Date calculation for Labor spend. It finds the latest date in view (today or the last filtered date), checks which fiscal year that date is in (currently January 1st to December 31st), and totals Labor spend from the start of that fiscal year through the latest date. If a Season is selected, it still starts from January 1st of that year, using the season's latest date only to pick the fiscal year.

</details>

<details>

<summary>Labor spend - previous year</summary>

Labor spend using a 364-day shift, which is 52 weeks back instead of a full calendar year. This means the comparison falls on the same day of the week as the current period, but not the same calendar date, and it can drift further during a leap year.

</details>

<details>

<summary>Labor spend - year to date previous year (Cards)</summary>

Labor spend year-to-date (Cards), shifted back 364 days, which is 52 weeks instead of a full calendar year. This means it lands on the same day of the week as the reference period, but not the same calendar date, and can drift further during a leap year.

</details>

<details>

<summary>Labor spend vs revenue as a percentage - last year</summary>

Labor spend year-to-date previous year (Cards) divided by booked revenue year-to-date previous year (Cards). This shows last year's labor cost as a share of revenue, with both values using the season-aware Year-to-Date range (the season's exact first-to-last date range if one is selected, otherwise January 1st through today, or through yesterday if today is the 1st of a month), shifted back 364 days (52 weeks, not a full calendar year). This means it lands on the same weekday as the current window, but not the same calendar date.

</details>

<details>

<summary>Labor hours worked - last year</summary>

Labor hours worked using a 364-day shift, which is 52 weeks back instead of a full calendar year. This means the comparison falls on the same day of the week as the current period, but not the same calendar date, and it can drift further during a leap year.

</details>

<details>

<summary>Labor hours worked - year to date</summary>

This is a Year-to-Date calculation for Labor hours worked. It finds the latest date in view (today or the last filtered date), checks which fiscal year that date is in (currently January 1st to December 31st), and totals Labor hours worked from the start of that fiscal year through the latest date. If a Season is selected, it still starts from January 1st of that year, using the season's latest date only to pick the fiscal year.

</details>

<details>

<summary>Wages - average hourly year to date</summary>

Labor spend year-to-date divided by labor hours worked year-to-date. This gives the average hourly wage for the year-to-date, using the standard Year-to-Date window from January 1st of the fiscal year with the latest date in view through that latest date, regardless of any Season selected.

</details>

<details>

<summary>Labor - Paid Total minus Labor - Paid Total LY</summary>

The dollar difference between this period's Labor spend and Labor spend from the previous year (using the 364-day shift, which is 52 weeks back instead of a full calendar year, so it lands on the same weekday as the reference period but not the same calendar date). This is a raw dollar gap, not a percentage.

</details>

<details>

<summary>Labor spend - year to date (Cards)</summary>

This is a season-aware Year-to-Date calculation for Labor spend. It checks if a Season filter is narrowing the report by comparing the filtered date range to the full range. If a season is selected, Labor spend is totaled from that season's first date to its last date. If no season is selected, the window is January 1st of the current year through today, except if today is the 1st of a month, in which case yesterday is used as the cutoff to avoid an artificially low or blank total before that day's data is complete.

</details>

<details>

<summary>Labor Spend - whole of previous year</summary>

This is a whole-of-previous-year calculation for Labor spend. It is not a 364-day shift, but is calculated as the entire prior fiscal year, from January 1st to December 31st of last year under current settings, or the equivalent full season-length window if a Season is selected.

</details>

<details>

<summary>Labor % Revenue YTD (Cards)</summary>

Labor - Percentage of Booked Revenue, evaluated over the season-aware Year-to-Date window (that season's own exact first-to-last date range if one is selected; otherwise January 1st through today, or through yesterday specifically if today is the 1st of a month).

</details>

<details>

<summary>Labor % Revenue YTD Previous Year (Cards)</summary>

The same percentage, but calculated over the season-aware year-to-date window shifted back 364 days (52 weeks, not a full calendar year). This means it lands on the same weekday as the reference period, not the same calendar date, and can drift further during a leap year.

</details>

<details>

<summary>Wages - average hourly year to date (cards)</summary>

Labor spend year-to-date (Cards) divided by Labor Hours Worked YTD (Cards). This gives the average hourly wage over the season-aware Year-to-Date window, using the season's exact first-to-last date range if one is selected; otherwise, it uses January 1st through today, or through yesterday if today is the 1st of a month.

</details>

<details>

<summary>Labor Hours Worked YTD (Cards)</summary>

This is a season-aware Year-to-Date calculation for Labor hours worked. It checks if a Season filter is narrowing the report by comparing the filtered date range to the full range. If a season is selected, Labor hours worked is totaled from that season's first date to its last date. If no season is selected, the window is January 1st of the current year through today, except if today is the 1st of a month, in which case yesterday is used as the cutoff to avoid an artificially low or blank total before that day's data is complete.

</details>

## Booked Revenue

<details>

<summary>Booked revenue</summary>

Booked revenue is calculated as the sum of BookingItem\[Amount] minus the sum of BookingItem\[Discount], excluding tax, for whatever is currently in view. Each line item is dated by its use date. This is the main revenue figure for the model.

</details>

<details>

<summary>Booked revenue - previous year</summary>

Booked revenue using the 364-day shift looks 52 weeks back instead of a full calendar year. This means the comparison falls on the same day of the week as the current period, but not the same calendar date. Over a leap year, the dates will drift further apart.

</details>

<details>

<summary>Booked revenue - year to date</summary>

This is a Year-to-Date calculation for Booked revenue. It finds the latest date in view (either today or the last filtered date), checks which fiscal year that date belongs to (currently January 1st to December 31st), and totals Booked revenue from the start of that fiscal year through the latest date. If a Season is selected, it only uses the season's latest date to pick the fiscal year, but still starts counting from January 1st of that year.

</details>

<details>

<summary>Booked revenue - year to date year over year growth as a percentage (Cards)</summary>

Booked Revenue - year to date (Cards) vs. Booked Revenue - year to date previous year (Cards), as a percent change.

</details>

<details>

<summary>Booked Revenue - year to date previous year (Cards)</summary>

Booked Revenue - year to date (Cards), shifted back 364 days, means it looks 52 weeks back instead of a full calendar year. This way, the comparison falls on the same day of the week as the reference period, but not the same calendar date. Over a leap year, the dates will drift further apart.

</details>

<details>

<summary>Booked revenue - Growth YoY</summary>

This shows the percent change between Booked revenue for the current period and Booked revenue from the previous year, using a 364-day shift (52 weeks back instead of a full calendar year). This means the comparison is on the same day of the week, not the same calendar date, and the dates drift further apart over a leap year.

</details>

<details>

<summary>Booked Revenue - year to date (Cards)</summary>

This is a season-aware Year-to-Date calculation for Booked revenue. It checks if a Season filter is being used by comparing the filtered date range to the full range. If a season is selected, Booked revenue is totaled from the season's first date to its last date. If no season is selected, the window is from January 1st of the current year through today. However, if today is the 1st of a month, yesterday is used as the cutoff to avoid an artificially low or blank total before that day's data is complete.

</details>

<details>

<summary>Booked revenue - future value booked before today's year-to-date</summary>

This is a more detailed figure. For the current fiscal year (or selected season), it looks at every booking-item date after an internally set "yesterday for the selected year" cutoff. It totals the Booked Revenue for those future-dated items, but only if they were already created or booked on or before that cutoff. In simple terms, this shows revenue for visits that have not happened yet this year, but guests have already paid for or committed to as of yesterday. This helps you see how much future business is already booked.

</details>

<details>

<summary>Booked revenue - future value booked before today year to date last year</summary>

This uses the same "already booked, for a future date" calculation as above, but it is run for the same point in the previous fiscal year. This gives you last year's total of already-booked future business to compare with this year's figure.

</details>

<details>

<summary>Booked Revenue - whole of previous year</summary>

This calculation totals Booked revenue for the entire previous fiscal year, from start to finish (January 1st to December 31st of last year, based on current settings). If a Season is selected, it uses the full season-length window instead. This is not a 364-day shift, but a direct calculation for the whole prior year.

</details>

<details>

<summary>Booked revenue - Growth</summary>

This is the dollar difference between this period's Booked revenue and Booked revenue from the previous year, using the 364-day shift (shifted back 52 weeks instead of a full calendar year, so it falls on the same weekday as the reference period, but not the same calendar date). This is a raw dollar gap, not a percentage.

</details>

<details>

<summary>Booked revenue - YTD PY</summary>

This takes the plain Year-to-Date figure (from January 1st of the fiscal year containing the latest date in view, through that latest date) and recalculates it for exactly one calendar year earlier. This is different from the "(Cards)" previous-year measures elsewhere in this folder. It is a true calendar-year shift (January 1st through the same date last year), not the 364-day or weekday-aligned shift used in other measures.

</details>

<details>

<summary>Booked revenue - YTD YoY %</summary>

Booked revenue - year to date vs. Booked revenue - YTD PY (the true calendar-year-shifted figure above), as a percent change.

</details>

<details>

<summary>Booked Revenue WTD</summary>

This is a week-to-date calculation for Booked revenue. It totals revenue from Monday of the current week (using Monday as the start, following ISO-style week numbering) through the latest date in view.

</details>

<details>

<summary>Booked Revenue MTD</summary>

This is a month-to-date calculation for Booked revenue, using DAX's standard calendar month-to-date logic. It totals revenue from the 1st day of the current month through the latest date in view. This is a true calendar-date comparison (for example, month-to-date through the 31st compares against month-to-date through the 31st of the reference period), not a weekday-based comparison.

</details>

<details>

<summary>Booked Revenue QTD</summary>

This is a quarter-to-date calculation for Booked revenue, using DAX's standard calendar quarter-to-date logic. It totals revenue from the 1st day of the current calendar quarter (January 1st, April 1st, July 1st, or October 1st) through the latest date in view.

</details>

<details>

<summary>Booked Revenue Same Day Last Week</summary>

This is a same-day-last-week calculation for Booked revenue. It compares a single day exactly 7 days before the latest date in view, matching one specific day to the same weekday one week earlier.

</details>

<details>

<summary>Average Daily Booked revenue</summary>

Booked revenue is divided by the count of non-blank values in the Date table's "Day of Week" column for whatever is in view. Since this column is filled for every date, this means Booked revenue divided by the number of distinct days currently in view, giving an average daily revenue figure.

</details>

<details>

<summary>Booked Revenue - month to date (Cards)</summary>

This measure works differently depending on whether a specific Month is selected on the page. If no Month is selected, it totals Booked Revenue from the 1st of the current calendar month through today, or through yesterday if today is the 1st. This is basically the same as the plain MTD measure. If a specific Month is selected, it does not stop at today. Instead, it matches that month to the fiscal calendar (choosing the correct year based on the fiscal-year start) and returns Booked Revenue for the entire selected month, from start to finish. So, if you pick a past or future month, this shows the full-month total, not just month-to-date. Only when no month is selected is the result truly "to date."

</details>

## Date

<details>

<summary>Date - Date Range</summary>

This is a text label that shows the first and last date in the current data, such as "1/1/2024 - 9/16/2026". It is meant for display in a report header and is not a numeric measure.

</details>

<details>

<summary>Date - Latest Date</summary>

This is a formatted text label for yesterday's date (today minus one day) in the en-GB date format. It is used for "data as of" labels on report pages.

</details>

<details>

<summary>Future Date Test</summary>

This measure shows booked revenue, but only for rows marked as a "future" date in the Date table. It is meant for development or testing, not for client-facing report pages.

</details>

<details>

<summary>Date - Cards min Date</summary>

This is an internal helper measure. It is not meant to be placed directly on a report, but is referenced by every season-aware "(Cards)" measure in both packs to calculate its window. It finds the start date of the season-aware Year-to-Date window by checking if a Season filter is narrowing the report. If a season is selected, it returns that season's first date. If no season is selected, it returns January 1st of the current fiscal year (currently the calendar year). However, if today is the 1st of a month, it uses yesterday instead of today, so the fiscal year can differ at a month boundary from what "today" alone would suggest.

</details>

<details>

<summary>Date - Card Max Date</summary>

This is an internal helper measure and is the counterpart to Date - Cards min Date. It finds the end date of the season-aware Year-to-Date window. If a Season is selected, it returns that season's last date. If no season is selected, it returns today's date. However, if today is the 1st of a month, it returns yesterday's date instead, likely to avoid a low or blank total before that day's data is available.

</details>

<details>

<summary>Date - FY min Date</summary>

This internal helper measure is used by every plain (non-"Cards") Year-to-Date measure. It takes the latest date currently in view (from Date - FY max Date below), finds which fiscal year that date is in based on the model's fiscal-year settings (currently January 1st to December 31st), and returns January 1st of that year as the start of the plain Year-to-Date window. Unlike the Cards version, it does not check for or use a Season's start date.

</details>

<details>

<summary>Date - FY max Date</summary>

This internal helper measure is simply the latest date in the current filter context (MAX('Date'\[Date])). It serves as the anchor point for every plain Year-to-Date measure and is the value that Date - FY min Date uses to determine the correct fiscal year.

</details>

<details>

<summary>Date - Cards End of Year Date</summary>

This internal helper is used only by Budget - this year or selected year (see below). It takes the season-aware Year-to-Date start date (from Date - Cards min Date) and adds exactly one year, then subtracts one day. This gives the full end of that fiscal year or season cycle, no matter what today's date is. Note: The measure also calculates a season-specific end date, but the final output always uses the one-year-after-start calculation, even if a Season is selected.

</details>

## Discount

<details>

<summary>Discount</summary>

This shows the total discount at the individual line-item level (BookingItem\[Discount]) for whatever is currently displayed. It is calculated per item, not per booking. For the booking-level discount, see Bookings - Value in the Booking folder. The two numbers can be different if a discount is split unevenly across a booking's line items.

</details>

<details>

<summary>Discount - average amount</summary>

This is the total item-level discount divided by the number of bookings with a promo code. The numerator adds up discounts at the item level, while the denominator counts bookings, not items. This means the result is not a true per-item or per-booking average, but a mix of both.

</details>

<details>

<summary>Discount - average percentage</summary>

This measure takes the average discount amount, multiplies it by the number of line items with a promo code, and then divides by the total booking amount (at the item level) for bookings with a promo code. This layered calculation gives an estimated average discount rate, so use it as a general guide rather than an exact percentage.

</details>

<details>

<summary>Discount WTD</summary>

This shows the week-to-date Discount, starting from Monday of the current week (using ISO week numbering) up to the latest date shown.

</details>

<details>

<summary>Discount MTD</summary>

This is the month-to-date Discount, calculated from the first day of the current month to the latest date shown. It uses DAX's standard calendar month-to-date logic, comparing true calendar dates rather than weekdays.

</details>

<details>

<summary>Discount QTD</summary>

This shows the quarter-to-date Discount, calculated from the first day of the current calendar quarter (January 1st, April 1st, July 1st, or October 1st) up to the latest date shown, using DAX's standard logic.

</details>

<details>

<summary>Discount Same Day LW</summary>

This measure shows the Discount for the same day last week, comparing a single day to the same weekday one week earlier. Unlike most 'Same Day LW' measures, this one uses DATEADD(..., -7, DAY), which shifts every date in the filter context back by 7 days. If you use this on a visual with more than one date selected, it will shift the whole range back a week instead of returning just one day's value. Keep this in mind if you use it outside of a single-day card.

</details>

## Employee

<details>

<summary>Employee - count</summary>

This shows the number of rows in the Employee table for what you are currently viewing. It does not filter by active or inactive status, so every employee record is counted, including those marked as inactive or terminated, unless the data only includes active staff.

</details>

## Transactions

<details>

<summary>Transactions - count</summary>

This shows the number of Booking Payment records for what you are currently viewing. Each payment transaction is counted once.

</details>

<details>

<summary>Transactions - average count per employee</summary>

Transactions - count divided by Employee - count.

</details>

<details>

<summary>Transactions - % of type</summary>

<mark style="color:$danger;">FLAG</mark>

</details>

## Parameter

<details>

<summary>Parameter - StartOfFiscalYear</summary>

This is the fiscal-year start month, taken from the model's settings table. It is currently set to 1 (January). All Year-to-Date, Whole-of-Previous-Year, and Last-Fiscal-Year measures use this value in real time. If you change it, those measures will update accordingly.

</details>

<details>

<summary>Parameter - StartDayOfFiscalYear</summary>

This is the fiscal-year start day of the month, taken from the model's settings table. It is currently set to 1. Combined with the month above, the fiscal year now starts on January 1st.

</details>

<details>

<summary>Parameter - Locale</summary>

This is the report's locale setting for date and number formatting. It is currently set to en-GB. This only affects how information is displayed, not how calculations are done.

</details>

<details>

<summary>Parameter - LastDayOfYear</summary>

This is the fiscal-year end date, taken from the model's settings table. It is currently set to 12/31, which matches a January 1st fiscal-year start.

</details>

## Revenue after Labor

<details>

<summary>Revenue after Labor</summary>

Booked revenue minus Labor spend for whatever is in view. This is a straightforward calculation with no extra logic. Previously, this measure was called "Gross Profit" and used a more complex, season-dependent method. The current version is simpler and works the same way whether or not a Season is selected.

</details>

<details>

<summary>Revenue After Labor LY</summary>

Booked revenue from the previous year minus Labor spend from the previous year, using a 364-day shift. This means it looks 52 weeks back instead of a full calendar year, so the comparison falls on the same day of the week as the current period, not the same calendar date. Over a leap year, the dates drift further apart. This is a same-weekday, not same-calendar-date, comparison.

</details>

<details>

<summary>Revenue after Labor - year to date</summary>

This is a Year-to-Date calculation for Revenue after Labor. It finds the latest date in view (either today or the last filtered date), checks which fiscal year that date is in (currently January 1st to December 31st), and totals Revenue after Labor from the start of that fiscal year through the latest date. If a Season is selected, it only uses the season's latest date to pick the fiscal year, but still starts counting from January 1st of that year.

</details>

<details>

<summary>Revenue after Labor Growth</summary>

This is the dollar difference between Revenue after Labor and Revenue After Labor LY, using a 364-day shift (52 weeks back instead of a full calendar year). This means the comparison falls on the same day of the week as the current period, not the same calendar date, and the dates drift further apart over a leap year. This is a raw dollar gap, not a percentage.

</details>

<details>

<summary>Revenue after Labor Growth (cards)</summary>

This is the dollar difference between Revenue After Labor - year to date (Cards) and Revenue after Labor - year to date previous year (Cards). It shows the raw dollar gap over the season-aware Year-to-Date window. If a season is selected, it uses that season's exact date range. Otherwise, it uses January 1st through today, or through yesterday if today is the 1st of a month.

</details>

<details>

<summary>Revenue After Labor - year to date (Cards)</summary>

This is a season-aware Year-to-Date calculation for Revenue after Labor. It checks if a Season filter is being used by comparing the filtered date range to the full range. If a season is selected, the window is that season's first date through its last date. If no season is selected, the window is January 1st of the current year through today. If today is the 1st of a month, it uses yesterday as the cutoff to avoid an artificially low or blank total before that day's data is complete.

</details>

<details>

<summary>Revenue after Labor - year-to-date previous year (Cards)</summary>

Revenue After Labor - year to date (Cards), shifted back 364 days (52 weeks instead of a full calendar year). This means it falls on the same day of the week as the reference period, not the same calendar date, and the dates drift further apart over a leap year.

</details>

<details>

<summary>Revenue after Labor Growth % (cards)</summary>

Revenue after Labor Growth (cards) divided by Revenue after Labor - year to date previous year (Cards), shown as a percent change over the season-aware year-to-date window.

</details>

<details>

<summary>Revenue after Labor Growth %</summary>

Revenue after Labor Growth divided by Revenue After Labor LY, shown as a percent change using the 364-day shift. This is a 52-week shift instead of a full calendar year, so it compares the same weekday as the reference period, not the same calendar date.

</details>

## Budget

<details>

<summary>Budget - year to date</summary>

This calculation shows the year-to-date Budget. It finds the latest date in view (either today or the last filtered date), checks which fiscal year that date belongs to based on the model's settings (currently January 1st to December 31st), and totals the Budget from the start of that fiscal year up to the latest date. If a Season is selected, it does not use the Season's start date. Instead, it uses the Season's latest date to pick the fiscal year, but still starts counting from January 1st of that year.

</details>

<details>

<summary>Budget</summary>

This shows the total budgeted amount (Budget\[Amount]) for whatever is currently in view. Right now, the Budget table is empty, so all Budget-based measures will return 0 or blank until budget figures are loaded. Keep this in mind if a Budget card or variance looks blank on the live report.

</details>

<details>

<summary>Booked revenue budget variance</summary>

This is the booked revenue minus the Budget for whatever is in view. It shows the dollar variance, which is positive when actual revenue is higher than the budget.

</details>

<details>

<summary>Budget WTD</summary>

This calculation shows the Budget from Monday of the current week (using Monday as the start, following ISO week numbering) through the latest date in view.

</details>

<details>

<summary>Budget MTD</summary>

This is a month-to-date Budget calculation, using DAX's standard logic. It totals from the first day of the current month through the latest date in view. This compares true calendar dates, so month-to-date through the 31st is compared to the 31st of the reference period, not by weekday.

</details>

<details>

<summary>Budget QTD</summary>

This calculation shows the Budget from the first day of the current calendar quarter (January 1st, April 1st, July 1st, or October 1st) through the latest date in view, using DAX's standard quarter-to-date logic.

</details>

<details>

<summary>Budget Same Day LW</summary>

This calculation shows the Budget for the same day last week. It compares a single day exactly seven days before the latest date in view to the same weekday one week earlier. Like Discount Same Day LW, it uses DATEADD(..., -7, DAY), so if more than one date is selected, it shifts the whole range back a week instead of returning just one day's figure.

</details>

<details>

<summary>Booked revenue % budget</summary>

(Booked revenue minus Budget) divided by Budget. This shows the variance as a percentage of the budget, not as a dollar amount.

</details>

<details>

<summary>Budget - year to date (Cards)</summary>

This is a season-aware year-to-date Budget calculation. It checks if a Season filter is applied by comparing the filtered date range to the full range. If a season is selected, the Budget window is that season's first date through its last date. If no season is selected, the window is January 1st of the current year through today. If today is the 1st of a month, it uses yesterday as the cutoff to avoid a low or blank total before that day's data is available.

</details>

<details>

<summary>Budget Variance - year to date (Cards)</summary>

Booked revenue budget variance, evaluated over the season-aware Year-to-Date window (that season's own exact first-to-last date range if one is selected; otherwise January 1st through today, or through yesterday specifically if today is the 1st of a month).

</details>

<details>

<summary>Booked Revenue % Budget - year to date (Cards)</summary>

Booked revenue % budget, evaluated over the season-aware Year-to-Date window (that season's own exact first-to-last date range if one is selected; otherwise January 1st through today, or through yesterday specifically if today is the 1st of a month).

</details>

<details>

<summary>Booked revenue budget variance YTD</summary>

Booked revenue budget variance, evaluated over the plain Year-to-Date window (January 1st of the fiscal year containing the latest date in view, through that latest date, regardless of any Season selected).

</details>

<details>

<summary>Budget - this year or selected year</summary>

This measure shows the Budget from the Season-aware Year-to-Date start date through the full end of that fiscal year (using Date - Cards End of Year Date), not stopping at today. In other words, it displays the entire current or selected fiscal year or season's budget, including months that haven't happened yet, rather than just a to-date figure.

</details>

<details>

<summary>Budget - full month</summary>

This measure works like the Booked Revenue - month to date (Cards) measure above, but always returns the full month's budget, no matter if a month is selected. If no month is selected, it uses the current calendar month from start to end, not stopping at today. If a month is selected, it matches that month to the fiscal calendar and returns its full-month budget. Unlike the Booked Revenue version, there is no 'stop at today' case here. This measure always gives a full-month total.

</details>

## Sessions

<details>

<summary>M2 - Session Attendance - Yesterday</summary>

M2 - Session Attendance (see below), filtered to just one day: yesterday, which means today's date minus one. This always shows the actual day before the report is opened and does not depend on any date filter on the page.

</details>

<details>

<summary>M2 - Session Attendance</summary>

Total quantity sold (BookingItem\[Quantity]) is counted only for line items with a non-blank, non-midnight 'ValidFrom' time. In this model, a 'session' means a booking item with a real scheduled time, not an all-day or undated item. Right now, the ValidFrom field is empty in the data, so all measures in this Sessions folder return blank until that field is filled.

</details>

<details>

<summary>M2 - Session Revenue</summary>

Total BookingItem\[TotalAmount] (which includes tax, unlike the Booked Revenue or Amount-minus-Discount used elsewhere) is limited to items with a real session time, just like M2 - Session Attendance. This uses a different revenue basis than other measures in the model, so direct comparisons with Booked Revenue for the same period will not match exactly.

</details>

<details>

<summary>M2 - Sessions with Sales</summary>

This is a count of unique sessions (by date and time) where at least one item was sold. It does not count line items or attendees, only session events with sales, and only if they have a real session time.

</details>

<details>

<summary>M2 - Session Attendance - Last 7 Days</summary>

M2 - Session Attendance for the seven calendar days ending with yesterday (that is, yesterday and the six days before). This does not include today. See 'Yesterday' and 'Last 7 Days' above.

</details>

<details>

<summary>M2 - Session Revenue - Last 7 Days</summary>

M2 - Session Revenue for the 7 calendar days ending yesterday.

</details>

<details>

<summary>M2 - Sessions with Sales - Last 7 Days</summary>

M2 - Sessions with Sales for the 7 calendar days ending yesterday.

</details>

<details>

<summary>M2 - Average Attendance per Session - Last 7 Days</summary>

M2 - Session Attendance - Last 7 Days divided by M2 - Sessions with Sales - Last 7 Days. Both values use the same seven-day period, so the ratio is consistent.

</details>

<details>

<summary>M2 - Average Revenue per Session - Last 7 Days</summary>

M2 - Session Revenue - Last 7 Days divided by M2 - Sessions with Sales - Last 7 Days. Both values cover the same seven-day period.

</details>

<details>

<summary>M2 - Session Attendance LY</summary>

M2 - Session Attendance for one day: yesterday, but shifted back 364 days (a 52-week shift, not a full calendar year). This lands on the same weekday as the reference period, but not the same calendar date from a year ago.

</details>

<details>

<summary>M2 - Session Revenue - Yesterday</summary>

M2 - Session Revenue filtered to yesterday only.

</details>

<details>

<summary>M2 - Sessions with Sales - Yesterday</summary>

M2 - Sessions with Sales filtered to yesterday only.

</details>

<details>

<summary><mark style="color:$danger;">M2 - Average Attendance per Session - Yesterday</mark></summary>

FLAG

</details>

<details>

<summary>M2 - Average Revenue per Session - Yesterday</summary>

M2 - Session Revenue - Yesterday divided by M2 - Sessions with Sales - Yesterday. Both values are from yesterday of the current year.

</details>

<details>

<summary>M2 - Session Revenue - Last Fiscal Year</summary>

M2 - Session Revenue is calculated for the entire most recently completed fiscal year. This is not a 364-day shift and is not based on today's date. It covers the full January 1st to December 31st period just before the current year.

</details>

<details>

<summary>M2 - Sessions with Sales - Last Fiscal Year</summary>

M2 - Sessions with Sales is calculated for the entire most recently completed fiscal year. This is not a 364-day shift and does not depend on today's date. It covers the full January 1st to December 31st period just before the current year.

</details>

<details>

<summary>M2 - Session Attendance - Last Fiscal Year</summary>

M2 - Session Attendance is calculated for the entire most recently completed fiscal year. This is not a 364-day shift and is not based on today's date. It covers the full January 1st to December 31st period just before the current year.

</details>

<details>

<summary>M2 - Average Attendance per Session - Last Fiscal Year</summary>

M2 - Session Attendance - Last Fiscal Year divided by M2 - Sessions with Sales - Last Fiscal Year — both sides over the same complete prior fiscal year.

</details>

<details>

<summary>M2 - Average Revenue per Session - Last Fiscal Year</summary>

M2 - Session Revenue - Last Fiscal Year divided by M2 - Sessions with Sales - Last Fiscal Year — both sides over the same complete prior fiscal year.

</details>

<details>

<summary>Avg Sessions by Date</summary>

Total quantity sold across all booking items, divided by the number of unique dates where Product\[SubType] is not blank. Right now, SubType is empty in the Product table, so the denominator is zero and the measure returns blank in live data. Check with the model owner if SubType should be filled, since this calculation only works if it is.

</details>

<details>

<summary>Sessions Pace - LY</summary>

This is a pace calculation for session attendance: M2 - Session Attendance for the date window shifted back 364 days (52 weeks, not a full calendar year). It is further limited to booking items that were already created by that same 364-days-back cutoff. This is a booking-pace comparison, not just a calendar comparison.

</details>

<details>

<summary>Sessions - Nominal Growth This Year vs Pace LY</summary>

This is the dollar difference between M2 - Session Attendance and Sessions Pace - LY. It compares this year's actual session attendance to last year's booking pace at the same point in time.

</details>

## Pace Revenue

<details>

<summary>Pace Revenue</summary>

This calculation looks at Booked revenue by moving the date window back 364 days, or 52 weeks. It only compares booking items that were already created by that same cutoff last year. This helps answer how much of last year's business, for the same period, had already been booked by this point in last year's cycle.

</details>

<details>

<summary>Pace Revenue - Nominal Growth This Year vs Pace LY</summary>

This shows the dollar difference between this year's actual Booked revenue and last year's Pace Revenue at the same point in the booking cycle.

</details>

<details>

<summary>Pace Revenue - Percentage Growth This Year vs Pace LY</summary>

This is the same difference as above, but divided by Pace Revenue and shown as a percentage.

</details>

<details>

<summary>Pace Revenue - Estimate Revenue based on Pace</summary>

This takes this year's pace-growth percentage and applies it to last year's total Booked revenue, then adds last year's actual revenue back in. This gives a projection of where this year might end up if the current growth rate continues.

</details>
